Open jdoe29103 opened 1 year ago
@jdoe29103
You're supposed to have a volume mapping to /downloads
not /data/torrents
in the linuxserver/qbittorrent
container. Details of the options available can be found here: https://docs.linuxserver.io/images/docker-qbittorrent
@bnhf the volumes are irrelevant to my issue. The default mappings from linuxserver are not good for my use case and they can be changed without issue. The volumes I have mapped are very intentional. Your response is irrelevant to my issue.
@jdoe29103
My apologies then, I always thought those volume mappings mattered. :-)
@bnhf no worries I can see why one would assume that. The /downloads part of the mapping is just a made up path that will be seen by whatever you are running in your container so you can change it to anything you want as long as whatever app you are using is configured with that same path.
@jdoe29103
You're probably ahead of me on this one, but I see in the linuxserver/qbittorrent Github page that they have the "temp" directory set to /downloads in the qbittorrent configuration file. I don't see where that path is exposed in the WebUI, so is it possible you're using up whatever free space is available in the container and a restart clears it out?
I'm also facing this issue. Looks like it might be a qBittorrent
issue since gluetun
seems to maintain the connection.
A (not nice) solution that I ended up using it adding this in the docker-compose for qbittorrent:
healthcheck:
test: ping 1.1.1.1 -nqc 1 -W 4 > /dev/null 2>&1 || exit 1
interval: 60s
retries: 5
start_period: 20s
timeout: 10s
depends_on:
gluetun:
condition: service_healthy
@SinTan1729 @bnhf thanks for your input :+1:
@SinTan1729
A (not nice) solution that I ended up using it adding this in the docker-compose for qbittorrent:
So qbittorrent loses connectivity completely? Are you sure the whole gluetun container doesn't get restarted? If it does, then it makes sense qbittorrent loses connectivity, subscribe to #641
@jdoe29103 welcome to gluetun first :wink: Your problem might be related to #1273 and also maybe a new bug in qbittorrent? Have you tried a previous tagged image for qbittorrent? Maybe also have a try with another client like Deluge? :thinking:
So qbittorrent loses connectivity completely? Are you sure the whole gluetun container doesn't get restarted? If it does, then it makes sense qbittorrent loses connectivity, subscribe to #641
From the logs, doesn't look like gluetun is restarting. Instead, it's updating the VPN details (i.e. IP etc.). In some cases, I'm not even able to find such an event, so qBittorrent is losing internet seemingly randomly.
@SinTan1729 I have been poking around with it the past week and I may have found a somewhat "better" fix. The other day I installed some updates on my OPNsense router which required a reboot. While the router rebooted I watched qBittorrent to see if it would recover once the router came back online and sure enough it did not and all torrents were stalled. However, after some trial and error it seems that binding the local IP address in qBittorrent's advanced settings resolved this issue. It can survive a router reboot and come back online after I changed this. It has been going strong for a few days now so we shall see.
@qdm12 It could be. I have had this issue in the past with much older versions of qbittorrent in combination with OpenVPN. I have not tested an older version of qbittorrent with gluetun yet so that could also be a potential fix. I am going to poke around with it a bit more sometime this week and see what I can find.
A (not nice) solution that I ended up using it adding this in the docker-compose for qbittorrent:
healthcheck: test: ping 1.1.1.1 -nqc 1 > /dev/null 2>&1 || exit 1 interval: 60s retries: 5 start_period: 20s timeout: 10s depends_on: gluetun: condition: service_healthy
@SinTan1729 does this cause qbittorrent to reboot if the gluetun container is restarted?
@SinTan1729 does this cause qbittorrent to reboot if the gluetun container is restarted?
Yes, it does.
@jdoe29103 Although, it doesn't really solve the issue as I just noticed that qBittorrent isn't working (i.e. it can't connect to trackers, fails the ipleak torrent test etc.) but I manually checked that I can ping from inside the container. I'll try out the address binding method that you suggested.
Update: I bound it to the network tun0
instead of a specific IP, and that seems to be working well (it has the advantage that qBittorrent binds to both IPV4 and IPV6, and some of my private trackers seem to perform better with one or the other). My guess it that whenever the network from gluetun
went down, qBittorrent
bound itself to another network (which isn't really connected to the internet) and for some reason refused to bind to tun0
when it came back on. So, restricting it to the proper network works.
Update: I bound it to the network tun0 instead of a specific IP, and that seems to be working well (it has the advantage that qBittorrent binds to both IPV4 and IPV6, and some of my private trackers seem to perform better with one or the other). My guess it that whenever the network from gluetun went down, qBittorrent bound itself to another network (which isn't really connected to the internet) and for some reason refused to bind to tun0 when it came back on. So, restricting it to the proper network works.
Glad it's working for you too. Your explanation makes perfect sense to me as well. @qdm12 Do you think you could add this into the documentation somewhere to help future users?
@SinTan1729 does this cause qbittorrent to reboot if the gluetun container is restarted?
Yes, it does.
@jdoe29103 Although, it doesn't really solve the issue as I just noticed that qBittorrent isn't working (i.e. it can't connect to trackers, fails the ipleak torrent test etc.) but I manually checked that I can ping from inside the container. I'll try out the address binding method that you suggested.
Update: I bound it to the network
tun0
instead of a specific IP, and that seems to be working well (it has the advantage that qBittorrent binds to both IPV4 and IPV6, and some of my private trackers seem to perform better with one or the other). My guess it that whenever the network fromgluetun
went down,qBittorrent
bound itself to another network (which isn't really connected to the internet) and for some reason refused to bind totun0
when it came back on. So, restricting it to the proper network works.
Yeah I had a similar issue a year ago and went through the exact same process. I tried doing a health check hack and it worked just fine but was annoying. The solution turned out to be setting a specific interface in the qbittorrent settings and binding to all ipv4 addresses on it.
So it seems the issue is not completely resolved. I noticed this morning that many torrents were unable to connect to trackers and adding new torrents just stalled. It seems the issue still persists sadly.
I've also been running into this issue and I've been bound to the tun0 adapter from the beginning. I have found a 100% repro rate with AirVpn, if you manually disconnect the session gluten is using through their website this issue will occur upon reconnection. Hopefully this will help someone more experienced find what's happening as I haven't been able to find out why yet 😁
I encounter this problem as well, qbittorrent "stalls" when gluetun restart
I guess this should be fixed/configurable on qbittorrent side since it can happen for the network to go down
Similar issue here; moved from a deprecated combo container to this plus linuxserver qbittorrent and qbittorrent works for a while, then loses connectivity until I restart the container.
I suspect the issue is with qbittorent, as my sonarr and jackett containers use gluetun fine...
I've done some digging and it looks like the problem is with libtorrent https://github.com/arvidn/libtorrent/issues/4412 Not sure what we can do on this end except reconnect less often, obviously not really a solution 😔 Unless we can somehow restart qbittorrent container when gluetun goes from unhealthy to healthy?
Update:
I might have found a solution to this but it's a little to early to tell. I've been using the linuxserver version of qBittorrent and after a little investigation they seems to default to the libtorrent 2.0 version.
I've now updated my container to use the lscr.io/linuxserver/qbittorrent:libtorrentv1
image and, for the moment, VPN disconnections no longer cause qBittorrent to lose connection and the ports stay/re open.
I'll keep this updated but hopefully this will hold 😁
After a power outage last night Qbittorrent rebooted and was connected to trackers but my client was not connectable. It seems Qbittorrent is just generally unreliable and I might just look for another client as I have been suffering with issues with this software for the better part of a decade.
Update: I might have found a solution to this but it's a little to early to tell. I've been using the linuxserver version of qBittorrent and after a little investigation they seems to default to the libtorrent 2.0 version. I've now updated my container to use the
lscr.io/linuxserver/qbittorrent:libtorrentv1
image and, for the moment, VPN disconnections no longer cause qBittorrent to lose connection and the ports stay/re open. I'll keep this updated but hopefully this will hold grin
This does not work for me, I can see the used libtorrent version is 1.x but the torrents still get stucks from time to time
Update: I might have found a solution to this but it's a little to early to tell. I've been using the linuxserver version of qBittorrent and after a little investigation they seems to default to the libtorrent 2.0 version. I've now updated my container to use the
lscr.io/linuxserver/qbittorrent:libtorrentv1
image and, for the moment, VPN disconnections no longer cause qBittorrent to lose connection and the ports stay/re open. I'll keep this updated but hopefully this will hold grinThis does not work for me, I can see the used libtorrent version is 1.x but the torrents still get stucks from time to time
I never updated here, but I had also tried the 1.x libtorrent version of qbittorent with no positive changes. I've resorted to just restarting my container occasionally =(
I may try the healthcheck item referenced above if I get a chance.
Update: I might have found a solution to this but it's a little to early to tell. I've been using the linuxserver version of qBittorrent and after a little investigation they seems to default to the libtorrent 2.0 version. I've now updated my container to use the
lscr.io/linuxserver/qbittorrent:libtorrentv1
image and, for the moment, VPN disconnections no longer cause qBittorrent to lose connection and the ports stay/re open. I'll keep this updated but hopefully this will hold grinThis does not work for me, I can see the used libtorrent version is 1.x but the torrents still get stucks from time to time
I never updated here, but I had also tried the 1.x libtorrent version of qbittorent with no positive changes. I've resorted to just restarting my container occasionally =(
I may try the healthcheck item referenced above if I get a chance.
I was able to resolve the issue by reverting back to libtorrent 1.x AND binding network interface to "tun0" and IP address to "All IPv4" Container has been up for 15 days without issues.
I was able to resolve the issue by reverting back to libtorrent 1.x AND binding network interface to "tun0" and IP address to "All IPv4" Container has been up for 15 days without issues.
Could you share your compose config? Just not sure how to bind it to tun0
@capsel22 No need for the config. It can be done in the settings. I believe it's right on top of the advanced/connections settings tab.
I was able to resolve the issue by reverting back to libtorrent 1.x AND binding network interface to "tun0" and IP address to "All IPv4" Container has been up for 15 days without issues.
This is working for me for several days so far. Thanks!
Just wanted to say qBittorrent works absolutely fine when I bind it to "tun0" and IP address to "All IPv4". Didn't even have to use libtorrent 1.x container. Thanks for everyone's advise
For me, just binding it to tun0
is enough. Been working for around 3 months.
binding tun0 and ipv4 does not resolve for me on the latest gluetun (v3.33.0) and qb (lscr.io/linuxserver/qbittorrent) release
I'm similar to ksurl
Latest gluetun and linuxserver/qbittorrent, networked through gluetun using --network=container:gluetun
, loses connection periodically, and seems to related to gluetun losing the VPN connection briefly (maybe?)
You've both said you're using linuxserver/qbittorrent, have you tried linuxserver/qbittorrent:libtorrentv1 with these settings? Curious to see if it helps you too
Thats what I need to do. Bind tun0 in qbit settings and use libtorrentv1 image. Works like a dream
I haven't tried but next time it happens I will try that.
problem is that is a really old image and doesn't get updated. i'm going to test the longer timeout first.
problem is that is a really old image and doesn't get updated. i'm going to test the longer timeout first.
That branch gets updated as regularly as the normal release. https://hub.docker.com/layers/linuxserver/qbittorrent/libtorrentv1/images/sha256-8b1f7e6361c007fcb560b9e7307e8540760d5f8b660f323a96124b4dc9387d4b?context=explore It's just built using libtorrentv1 instead of the newer, less stable version of libtorrent.
No issues for me since I went to qbittorrent with v1 libtorrent
problem is that is a really old image and doesn't get updated. i'm going to test the longer timeout first.
That branch gets updated as regularly as the normal release.
It's just built using libtorrentv1 instead of the newer, less stable version of libtorrent.
Oh, I'll give it a try if the timeout is insufficient
I haven't tried but next time it happens I will try that.
Coming back to say that using a version of libtorrentv1
wasn't enough, it died again after a week, but using a version of libtorrentv1
AND binding qBittorrent to the wg0
interface was rock solid for a month.
Thanks all.
Is the ultimate solution to use the libtorrentv1
version? Has anyone opened an issue for this either in qBittorrent and/or LibTorrent?
Seems pretty widespread from Googling.
Is the ultimate solution to use the
libtorrentv1
version? Has anyone opened an issue for this either in qBittorrent and/or LibTorrent?Seems pretty widespread from Googling.
the workaround is using portcheck alongside qb if you don't want to switch to a different client like transmission.
Is the ultimate solution to use the
libtorrentv1
version? Has anyone opened an issue for this either in qBittorrent and/or LibTorrent? Seems pretty widespread from Googling.the workaround is using portcheck alongside qb if you don't want to switch to a different client like transmission.
Sorry for needing some hand-holding, but could you link some docs to the portcheck you're referring to? Or are you referring to generally checking the port with a healthcheck in docker compose or something?
I just want to share a solution I managed to get working, with qBitTorrent 4.6.4 on linux. I run a script that detects if the "dht_nodes" drop to zero and if it stays at zero for a bit then it fully stops qBitTorrent and starts it again.
#!/bin/sh
while true
do
sleep 60
# Get the cookies if did not before
[ -f /tmp/.cookies.txt ] || curl -s -b /tmp/.cookies.txt -c /tmp/.cookies.txt --header 'Referer: http://127.0.0.1:YOURPORT' --data 'username=YOURUSERNAME&password=YOURPASSWORD' http://127.0.0.1:YOURPORT/api/v2/auth/login
# Check if dht_nodes is zero every minute
if [ "$(curl -s -b /tmp/.cookies.txt -c /tmp/.cookies.txt --header 'Referer: http://127.0.0.1:YOURPORT' http://127.0.0.1:YOURPORT/api/v2/transfer/info | jq '.dht_nodes')" -eq "0" ]
then
failcount=$((failcount+1))
else
failcount=0
fi
# If dht_nodes is zero for 5 minutes, restart qBitTorrent
if [ $failcount -gt 5 ]
then
/etc/init.d/qBittorrent.sh stop
sleep 20
/etc/init.d/qBittorrent.sh start
fi
done &
You need curl
and jq
, also edit YOURUSERNAME, YOURPASSWORD and YOURPORT to your case.
I just want to share a solution I managed to get working, with qBitTorrent 4.6.4 on linux. I run a script that detects if the "dht_nodes" drop to zero and if it stays at zero for a bit then it fully stops qBitTorrent and starts it again.
You need
curl
andjq
, also edit YOURUSERNAME, YOURPASSWORD and YOURPORT to your case.
Can you please give a bit more context on how you got it working in qbittorrent container and What (name) did you save this code and where did you save this (inside/outside the container) and is this run inside the qb container or outside?
I am very sorry, but when I posted here I did not realize this was specifically for a container solution... my bad. Still I suppose it should be easy to apply. I run qBittorrent in my QNAP server, not in a container, but the script is saved in /etc/init.d as S99qbittorentwatch I think you need to run inside the container, because of the 127.0.0.1 address, change YOURPORT to the port you have qBittorrent listening, and also change /etc/init.d/qBittorrent.sh to the script that runs qBittorrent at boot.
Is this urgent?
None
Host OS
Latest version of OpenMediaVault
CPU arch
x86_64
VPN service provider
Mullvad
What are you using to run the container
docker-compose
What is the version of Gluetun
I don't see this line in my logs
What's the problem 🤔
I recently switched from using an old deprecated docker container for qBittorrent with OVPN support built in. I am now running the latest qBittorrent docker from linuxserver along with gluetun using Mullvad/Wireguard. My issue is that qBittorrent will connect to torrents and work just fine for awhile but it will eventually become unable to connect to any peers. I do not know if this is a qBittorrent issue or a gluetun issue. Restarting the qBittorrent container solves the issue temporarily.
Share your logs
Share your configuration