starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Process never exits: still receiving new TCP connections. #5289

New issue

Closed

opened 2026-02-21 17:46:31 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-21 17:46:31 -05:00

Owner

Originally created by @Meneth32 on GitHub (Mar 4, 2017).

qBittorrent version and Operating System:

v3.3.10, Windows 7.

What is the problem:

After choosing Exit, the window closes and the taskbar icon disappears, process never shuts down.

What is the expected behavior:

The qbittorrent.exe process should quit within one second of the window closing. The program may take some time before then, to save state and flush all files, but it should do so visibly.

Steps to reproduce:

Have a few hundred torrents active, and live Internet capable of receiving incoming TCP connections.

Extra info(if any):

Using Process Hacker, I could see that long after closing the window, qbittorrent.exe was still listening for incoming connections on 0.0.0.0, port 29000-and-change. It was also receiving new connections from the Internet every few seconds. I suspect this activity prevented the process from exiting.

I could also see that there was no disk activity, as expected.

I suggest that a policy be instated that all files and sockets must be closed before the window is closed, preventing these kind of zombie processes.

Originally created by @Meneth32 on GitHub (Mar 4, 2017). ### qBittorrent version and Operating System: v3.3.10, Windows 7. ### What is the problem: After choosing Exit, the window closes and the taskbar icon disappears, process never shuts down. ### What is the expected behavior: The qbittorrent.exe process should quit within one second of the window closing. The program may take some time before then, to save state and flush all files, but it should do so **visibly**. ### Steps to reproduce: Have a few hundred torrents active, and live Internet capable of receiving incoming TCP connections. ### Extra info(if any): Using [Process Hacker](https://wj32.org/processhacker/), I could see that long after closing the window, qbittorrent.exe was still listening for incoming connections on 0.0.0.0, port 29000-and-change. It was also receiving new connections from the Internet every few seconds. I suspect this activity prevented the process from exiting. I could also see that there was no disk activity, as expected. I suggest that a policy be instated that all files and sockets must be closed before the window is closed, preventing these kind of zombie processes.

deekerman

2026-02-21 17:46:31 -05:00

closed this issue
added the
Duplicate
label

deekerman commented

2026-02-21 17:46:35 -05:00

Author

Owner

@Chocobo1 commented on GitHub (Mar 4, 2017):

Is this always reproducible for you? just curious, how long did you waited?

@Chocobo1 commented on GitHub (Mar 4, 2017): Is this always reproducible for you? just curious, how long did you waited?

deekerman commented

2026-02-21 17:46:36 -05:00

Author

Owner

@Meneth32 commented on GitHub (Mar 4, 2017):

I've observed it once so far; I waited about 5 to 10 minutes that time. I don't normally quit qBT often, but v3.3.11 just came out, so let's try again with that...

Could not reproduce directly. The IPv4 listening socket was closed quickly, the IPv6 socket stayed open a longer, and the process stuck around for maybe 5-10 seconds after the window was closed, but overall it seems to work acceptably now. Feel free to close this issue if no one else can reproduce.

@Meneth32 commented on GitHub (Mar 4, 2017): I've observed it once so far; I waited about 5 to 10 minutes that time. I don't normally quit qBT often, but v3.3.11 just came out, so let's try again with that... Could not reproduce directly. The IPv4 listening socket was closed quickly, the IPv6 socket stayed open a longer, and the process stuck around for maybe 5-10 seconds after the window was closed, but overall it seems to work acceptably now. Feel free to close this issue if no one else can reproduce.

deekerman commented

2026-02-21 17:46:36 -05:00

Author

Owner

@rsgabriel commented on GitHub (Apr 6, 2017):

Experiencing the same issue. Observed with process explorer. the TCP/IP tab shows connections being closed and opened to remote addresses. Seeding several thousand torrents.

I've seen the process stay open for hours after selecting Exit from the UI but also seen it eventually close (after maybe 15 minutes).

Ending process usually results in data loss where torrents must be partially or fully redownloaded. Sometimes qBittorent simply can't see the downloaded data and marks the torrent as 0.0% complete. Forcing a recheck fails. Open containing folder shows the files in their final destination and are in-tact and functional.

edit: Perhaps relevant, when exiting I always have active transfers.

@rsgabriel commented on GitHub (Apr 6, 2017): Experiencing the same issue. Observed with process explorer. the TCP/IP tab shows connections being closed and opened to remote addresses. Seeding several thousand torrents. I've seen the process stay open for hours after selecting Exit from the UI but also seen it eventually close (after maybe 15 minutes). Ending process usually results in data loss where torrents must be partially or fully redownloaded. Sometimes qBittorent simply can't see the downloaded data and marks the torrent as 0.0% complete. Forcing a recheck fails. Open containing folder shows the files in their final destination and are in-tact and functional. edit: Perhaps relevant, when exiting I always have active transfers.

deekerman commented

2026-02-21 17:46:36 -05:00

Author

Owner

@fbriere commented on GitHub (May 2, 2017):

Could this possibly be related to #5097?

@fbriere commented on GitHub (May 2, 2017): Could this possibly be related to #5097?

deekerman commented

2026-02-21 17:46:37 -05:00

Author

Owner

@zeule commented on GitHub (May 2, 2017):

It duplicates #5097 most likely, since there the process hangs in boost asio network code. So, actually, this is bug in libtorrent or boost.

@zeule commented on GitHub (May 2, 2017): It duplicates #5097 most likely, since there the process hangs in boost asio network code. So, actually, this is bug in libtorrent or boost.

deekerman commented

2026-02-21 17:46:37 -05:00

Author

Owner

@BloodyRain2k commented on GitHub (Jul 21, 2017):

I'm seeing the same behaviour of opening several dozen connections at once just to immediately close them again with 3.3.14
It seems to open and close ALL ports from 49000 up to somewhere around 63000. For TCPv4 this works within a few seconds, the same process for TCPv6 however takes minutes.

And it's very reproducible for me, I can just start qBit and close it 1min later and I will have to wait 5min or more for it to get through with this.
What's more interesting is that I don't even have "Listen on IPv6" enabled.

I also got several thousand torrents 'active', as in they're to be downloaded but 99.9% barely have any activity in a month to begin with, actual activity is very tame and tends to be mostly in-progress ones uploading a little.

@BloodyRain2k commented on GitHub (Jul 21, 2017): I'm seeing the same behaviour of opening several dozen connections at once just to immediately close them again with 3.3.14 It seems to open and close ALL ports from 49000 up to somewhere around 63000. For TCPv4 this works within a few seconds, the same process for TCPv6 however takes minutes. And it's very reproducible for me, I can just start qBit and close it 1min later and I will have to wait 5min or more for it to get through with this. What's more interesting is that I don't even have "Listen on IPv6" enabled. I also got several thousand torrents 'active', as in they're to be downloaded but 99.9% barely have any activity in a month to begin with, actual activity is very tame and tends to be mostly in-progress ones uploading a little.

deekerman commented

2026-02-21 17:46:37 -05:00

Author

Owner

@Seeker2 commented on GitHub (Jul 21, 2017):

Might this be aggravated further because qBT doesn't close out its UPnP incoming port/s in the early part of the process of shutting down? https://github.com/qbittorrent/qBittorrent/issues/5695

@Seeker2 commented on GitHub (Jul 21, 2017): Might this be aggravated further because qBT doesn't close out its UPnP incoming port/s in the early part of the process of shutting down? https://github.com/qbittorrent/qBittorrent/issues/5695

deekerman commented

2026-02-21 17:46:37 -05:00

Author

Owner

@zeule commented on GitHub (Jul 21, 2017):

@BloodyRain2k, do you have (at the time of closing) any trackers that qBt was not able to contact? Might it be arvidn/libtorrent@94701c24da?

@zeule commented on GitHub (Jul 21, 2017): @BloodyRain2k, do you have (at the time of closing) any trackers that qBt was not able to contact? Might it be arvidn/libtorrent@94701c24da1f1071afc98c70d27ea5c75d6ac56f?

deekerman commented

2026-02-21 17:46:37 -05:00

Author

Owner

@BloodyRain2k commented on GitHub (Jul 21, 2017):

@evsh very likely as many trackers that come with torrents are dead or broken, atleast for me.
Sadly qBit has yet to add the means to mass-cleanup the trackers, like removing all that are unreachable for extended periods of time and making a list of the ones that do work and then add these to all torrents that don't have them yet.
I tried doing that manually for a bit and while it did work in getting some torrents going that were inactive for months was the process so painful that I gave up eventually.

@BloodyRain2k commented on GitHub (Jul 21, 2017): @evsh very likely as many trackers that come with torrents are dead or broken, atleast for me. Sadly qBit has yet to add the means to mass-cleanup the trackers, like removing all that are unreachable for extended periods of time and making a list of the ones that do work and then add these to all torrents that don't have them yet. I tried doing that manually for a bit and while it did work in getting some torrents going that were inactive for months was the process so painful that I gave up eventually.

deekerman commented

2026-02-21 17:46:37 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Feb 19, 2020):

Duplicate of https://github.com/qbittorrent/qBittorrent/issues/5097

@FranciscoPombal commented on GitHub (Feb 19, 2020): Duplicate of https://github.com/qbittorrent/qBittorrent/issues/5097