mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
qbittorrent slows Ubuntu 13.04 to restart or change users #767
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#767
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SergeyAka on GitHub (Sep 25, 2013).
Ubuntu can't restart as fast as usually if Qbittorent is running.
I just hit Restart in system menu and about 15-20 seconds after that Ubuntu start restarting. Nothing happens at this time.
If I first manually close Qbittorent then Ubuntu restart normally fast.
I've finded similar bug https://bugs.launchpad.net/ubuntu/+source/qbittorrent/+bug/1068057
Qbittorrent ver. 3.0.11 http://s1.ipicture.ru/uploads/20130922/qj4l95Ah.png
Ubuntu 13.04 x64.
@sledgehammer999 commented on GitHub (Sep 25, 2013):
How many torrents do you have in your transferlist?
@sledgehammer999 commented on GitHub (Sep 25, 2013):
Oops, it seems that it is one from the screenshot. Is that a 7GB torrent?
Can you launch qbittorrent from the terminal and:
@SergeyAka commented on GitHub (Sep 25, 2013):
Launch qbittorrent from the terminal and exit it through the gui:
sergey@sergey-pc:
$ qbittorrent$Object::connect: No such slot TrackerList::editSelectedTracker()
Object::connect: No such slot TrackerList::editSelectedTracker()
Object::connect: No such slot PropertiesWidget::editWebSeed()
Object::connect: (receiver name: 'PropertiesWidget')
Object::connect: No such slot PropertiesWidget::editWebSeed()
Object::connect: (sender name: 'listWebSeeds')
Object::connect: (receiver name: 'PropertiesWidget')
virtual void RssFeed::refresh() Feed "LostFilm.TV" is already being refreshed, ignoring request
sergey@sergey-pc:
It takes about 2 seconds!
Video record of shuting down speed of qbittorrent. It's pretty fast in terminal.
https://docs.google.com/file/d/0B7LlK5UsbHJBR2RUUHp6ZlJxUFk/edit?usp=sharing
My current downloads
https://docs.google.com/file/d/0B7LlK5UsbHJBNHo1OVd1a2RvTVU/edit?usp=sharing
@SergeyAka commented on GitHub (Sep 27, 2013):
Is there any idea why qbittorrent slows Ubuntu?
@sledgehammer999 commented on GitHub (Sep 27, 2013):
The only thing I can think of is that when the OS is shutting down for some reason qbt is slow to respond and shutdown quickly.
I am not good with linux, is there anyway to observe how long qbt takes to exit during the OS shutdown process?
EDIT: I now, watched your video.
This isn't what I meant. killing a process doesn't count as exiting correctly. In terminal issue "qbittorrent". Wait for qbt to finish loading. At this point the terminal should not have returned. In qbt do a File->Exit and observe how long it takes for the terminal to return.
@SergeyAka commented on GitHub (Sep 27, 2013):
My English is not so good.
Hope these videos are exactly what you've asked for:
https://docs.google.com/file/d/0B7LlK5UsbHJBVUZxRVJ4aEpGc3M/edit?usp=sharing
https://docs.google.com/file/d/0B7LlK5UsbHJBVXB2b0hWUVNiRGc/edit?usp=sharing
https://docs.google.com/file/d/0B7LlK5UsbHJBY1VYaERhS00yQnc/edit?usp=sharing
https://docs.google.com/file/d/0B7LlK5UsbHJBU2ZZMEhWaVRFWm8/edit?usp=sharing
@Kervius commented on GitHub (Sep 28, 2013):
"Launch qbittorrent from the terminal and exit it through the gui:"
You should quit the qbt first.
In the video #4, the qbt's icon is already in the tray, meaning it is already running. Launch of qbt from terminal did nothing (but to bring the qbt window to the front). Due to this, the speed of shutdown cannot be seen in the terminal.
Try the steps:
@sledgehammer999 commented on GitHub (Sep 28, 2013):
This shows that qbt exits almost immediately after a "shutdown" has been issued. While this:
Other processes(like skype) don't exit although the system is shutting down.
I really don't know what the problem is here. But qbt is exiting immediately and shouldn't have any effect on your shutdown. Maybe the bug is in Ubuntu and not qbt?
@SergeyAka commented on GitHub (Sep 28, 2013):
Kervius, it seems qbt doesn't Exit with menu File->Exit.
Check this video: https://docs.google.com/file/d/0B7LlK5UsbHJBM3NDMlRRUWJXbWc/edit?usp=sharing
After 2 minutes command ps wuax | grep qbittorrent in terminal still have output. It's not empty.
But I can't find proces of qbittorrent in System monitor or utility HTOP.
P.S. I've got this result by following your advice:
https://docs.google.com/file/d/0B7LlK5UsbHJBbGFiOVFRYkU1cUU/edit?usp=sharing
The prompt of the shell:
sergey@sergey-pc:
$ qbittorrent$Object::connect: No such slot TrackerList::editSelectedTracker()
Object::connect: No such slot TrackerList::editSelectedTracker()
Object::connect: No such slot PropertiesWidget::editWebSeed()
Object::connect: (receiver name: 'PropertiesWidget')
Object::connect: No such slot PropertiesWidget::editWebSeed()
Object::connect: (sender name: 'listWebSeeds')
Object::connect: (receiver name: 'PropertiesWidget')
virtual void RssFeed::refresh() Feed "LostFilm.TV" is already being refreshed, ignoring request
virtual void RssFeed::refresh() Feed "NovaFiLM.TV" is already being refreshed, ignoring request
sergey@sergey-pc:
@Kervius commented on GitHub (Sep 29, 2013):
@SergeyAka
Output is not empty because you see the "grep" command itself in it.
You can cancel the effect by either adding "|grep -v grep" to the pipe or using the "pgrep qbittorrent" command instead. ("pgrep" displays only PIDs.)
The QBT has finished almost instantaneously.
Sergey, since you are in a mood for the tests. Another one:
Information of interest is: avgqu-sz column showing the size of (pending) IO queue.
Information of interest is: the amount of IO the QBT causes.
The point of the test is to see how much IO QBT causes when it terminates. Linux tends to speculatively delay IO activities. That would make QBT terminate fast even if it causes flurry of IO. But during shutdown, the IO is finalized and disks are synced, making OS (and user) to actually wait for the completion.
If IO is low/moderate, then I think it has nothing to do with IO. (Probably some interaction with the session manager?)
@SergeyAka commented on GitHub (Sep 29, 2013):
Ok, here are the results of commands:
pidstat https://docs.google.com/file/d/0B7LlK5UsbHJBcnE3OURoV01HU28/edit?usp=sharing
iostat https://docs.google.com/file/d/0B7LlK5UsbHJBWGt4NnZrOEVzMkE/edit?usp=sharing
I think analyze text file more convenient than read it on this page.
And video: https://docs.google.com/file/d/0B7LlK5UsbHJBQjdyTHcydGtRbzA/edit?usp=sharing
@Kervius commented on GitHub (Sep 29, 2013):
Absolutely nothing out of ordinary, what might impact the shutdown in any noticeable fashion.
@SergeyAka commented on GitHub (Sep 29, 2013):
P.S. I see message of recovering of VAR partion every time then Ubuntu starts. Maybe some app can't stop when Ubuntu shutdown. But this issue appeare before I installed QBT, maybe it's ffmpegthumbnailer.
@SergeyAka commented on GitHub (Sep 29, 2013):
Don't know it is usefull or not, but here is screenshot of tetminal with iostat -x 5 and pidstat -d 5 commands at the moment when Ubuntu goes to restart.

@SergeyAka commented on GitHub (Oct 17, 2013):
qbittorrent got update to 3.1.0 version. Now it works perfect. Thanx!
@sledgehammer999 commented on GitHub (Oct 17, 2013):
Awesome. Closing.