Stopping qbittorrent takes forever

[morfikov]

I was trying to target the problem, but I don't really know whether it's a bug or misconfiguration or some other things including my OS, so I'm asking here. Qbittorrent and qbittorrent-nox have exactly the same issue, which is that the process exits really slow when closing the applications. It doesn't really matter whether it's a system service (in this case qbittorrent-nox) or just a normal process called by the regular user under Xserver, usually qbittorrent. When I want to close them, I have to wait 20-30 secs before the process exits.

The only one thing I can tell is that when closing the apps, there's many DNS queries till the closing is done. Maybe that's the problem? Why is it making so many DNS queries at the stopping time? Is it a normal behavior? Of course, it's just an idea, and I'm not saying that the problem is buried here. But what else could prevent qbittorrent process from exiting? I have many ISO linux torrents to share (150+), so maybe it's because of that? I don't have ipv6, does it matter? Does anyone experience this kind of issue, or is it just me?

I'm using debian sid and the following version of qbittorrent:

Code: Select all

$ apt-cache policy qbittorrent
qbittorrent:
  Installed: 3.3.x~6312-20151029~wily1
  Candidate: 3.3.x~6312-20151029~wily1
  Version table:
 *** 3.3.x~6312-20151029~wily1 995
        120 http://ppa.launchpad.net/qbittorrent-team/qbittorrent-unstable/ubuntu wily/main amd64 Packages
        100 /var/lib/dpkg/status
     3.3.1-1 990
        990 http://ftp.de.debian.org/debian sid/main amd64 Packages

[ciaobaby]

The things that have the most effect on close down are:

The more active tasks there are, ... .... The longer it will take to close down.

The larger your cache is, ... ... The longer it will take to close down.

The longer the cache timeout/expiry is, ... ... The longer it will take to close down.

If you are on Windows and have elected to use OS caching, ... ... The longer it will take to close down.

DNS queries have very little to do with  shutdown, .... it will not necessarily wait for them to complete, ... ... But it may 'decide' to wait for tracker(s) to acknowledge the 'stopped' event when the shut down is 'graceful'.

[Peter]

Maybe it's half-open/open connections, and libtorrent tries to close them gracefully. Maybe.
Check netstat or any other similar tool and see if that makes sense.

(I have qBittorrent on my Linux home server and it shuts down in seconds.
But then it's only got a few torrents.)

[morfikov]

The more active tasks there are, ... .... The longer it will take to close down.

I think this is it. I just paused all the torrents and qbittorrent quits almost instantly. The cache is 16M/90s. Should it matter whether the torrents are being downloaded? I usually only upload and the tasks are completed. What about forcing qbittorrent to quit? Could there be any issues with that? For now, I've set 10s timeout, and most of the time systemd kills the process, but I don't see any corrupted torrents, etc. Is there anything else I can do about speeding it up?  I'm not gonna wait 30s when I want to reboot my pc.

DNS queries have very little to do with  shutdown, .... it will not necessarily wait for them to complete, ... ... But it may 'decide' to wait for tracker(s) to acknowledge the 'stopped' event when the shut down is 'graceful'.

What about trackers that are down for some reason?  Will they slow down the closing process? Should they be removed?

Maybe it's half-open/open connections, and libtorrent tries to close them gracefully. Maybe.
Check netstat or any other similar tool and see if that makes sense.

Actually, when qbittorent tries to close, almost all of the connections in netstat are closed instantly. There're actually two that say open. One of them points to the port for the incoming connections (only UDP), and the other connection is in the established state with my local dnsmasq server (cache DNS). But while qbittorrent is closing, I see many new connections in syn-sent state that comes and goes.

[ciaobaby]

Should they be removed?

Absolutely, unequivocally, YES and not just for close down times. Not 'pruning' dead trackers simply increases protocol overhead for no benefit.

What about forcing qbittorrent to quit?

If all tasks are complete there may be no problems, but next start up will most probably require a forced recheck of some, if not all, loaded tasks.

With tasks that are actively downloading pieces that are not committed to disk will be lost and all tasks WILL require a force recheck.

  I'm not gonna wait 30s when I want to reboot my pc.

If you are serious about 'torrenting' you should run you chosen bittorrent client on a machine that does not require frequent or regular reboots ( see index.php/topic,3703.msg19079/topicseen.html#msg19079), if you are a casual 'torrenter' then you have to live with, and allow for, the 'issues' that having to interrupt what is intended to be continuous process brings with it, and if that means waiting a whole 30 seconds or dealing with the consequence of not waiting (which will be longer than thirty seconds) then sobeit.

[morfikov]

I've cleaned up all the dead trackers leaving only 2-3 per torrent (the most popular), and now qbittorrent closes in 3-4s.

If all tasks are complete there may be no problems, but next start up will most probably require a forced recheck of some, if not all, loaded tasks.

Actually, qbittorrent seems to be pretty stable, and it doesn't rehash torrents after killing. The only situation I'm sure it will rehash is when I kill the app while I'm downloading something. So I always try to gracefully close qbittorrent in that case.

If you are serious about 'torrenting' you should run you chosen bittorrent client on a machine that does not require frequent or regular reboots ( see index.php/topic,3703.msg19079/topicseen.html#msg19079), if you are a casual 'torrenter' then you have to live with, and allow for, the 'issues' that having to interrupt what is intended to be continuous process brings with it, and if that means waiting a whole 30 seconds or dealing with the consequence of not waiting (which will be longer than thirty seconds) then sobeit.

Actually, I'm seeding all the time, but I don't have a separate machine for that. I'm using traffic control, and all the bandwidth that isn't currently used is utilized by torrents, and I don't even notice that I'm uploading something.