PaulieW

I'm glad you posted this. As you can read from my posts up a bit on this page, I am also having issues with running 2 binhex-qbittorrent containers. I thought initially it was due to the fact that I had routed the traffic of the 2nd one through the 1st. But when I separated them completely, eaching routing the traffic through Bridge and giving them each their own wg0.conf, the problem remained. So the cause had to be something else. When I read your post, it has nothing to do with the traffic routing, but with having both webUI's open in the same browser. So are you saying that if you open the first one as http://192.168.1.1:8080 and then second one as http://tower.local:8081, then there is no memory issue? As long as the hostname is different? Have you also just tried running one webUI in chrome and the other in firefox for instance? Edit: Can confirm both methods seem to do the trick! @binhexis this something you would look into?

Ok that makes sense yes, thank you!

I did not know both of these things, thanks for pointing that out! More generally speaking then, how do you yourself connect multiple binhex containers to the same VPN IP so that it only counts as 1 device for the VPN provider (and all containers being connectable/port forwarded)?

Shame. I was using the VPN connection inside the qbittorent container up to now like you are using, but that would mean that every qbittorrent container takes one device slot off of the VPN provider. And usually you only get 5 or maybe 7, so it would be nice if I could let all qbittorrent containers be connected through the same device as seen by the VPN provider. That's why I'm trying the VPN manager route. Would seem strange to me if the VPN Manager can't be setup to make port forwarding work.

@Zxurian did you manage to solve this? I'm running into the exact same issue, but then with binhex-qbittorrentvpn container. Or does somebody else know the answer?

Correct I added 4 VPN Output ports; 59142: The forwarded port provided by my VPN provider. Indeed this probably is not needed. 8081: The listening port of a 2nd binhex-qBit docker, so that its connection goes through the main qBit 8080 docker. 2468: Cross-seed 2469: Cross-seed of 2nd binhex-qBit docker But none of these could be having anything to do with memory piling up I imagine? Edit: Well apparently it had everything to with it lol. As soon as I start the 2nd binhex-qBit container, my available memory starts to drop significantly. I'm routing the traffic like this: As followed by @SpaceInvaderOne's guide: https://www.youtube.com/watch?v=znSu_FuKFW0&t=315s But it seems this network routing method doesn't work properly for 2 qBittorrent containers, causing memory leak issues. @binhex are you aware of such memory issues when 2 binhex-qbittorrent containers are routed as described?

Alright here goes, see attached. Anything useful in there? Seems all pretty generic to me. docker run qBit.txt

Thanks, I rolled back to 4.5.2 as that is apparently still a popular version being used. But to no avail: I started with 27GB free memory, and after launching qBit 4.5.2 this went down to 18GB within 20 minutes or so. And still dropping... Surely if everyone had this issue it would be a much more critical issue being dealt with. How can it be that others don't experience this but I do?

I'm experiencing a major memory leak using qBit, posted about it on the qBit github here: https://github.com/qbittorrent/qBittorrent/issues/20117#issuecomment-1998091075 Does any of you have the same issue? Can it be fixed at the container level or does it need to be addressed in qBit? Is there an option to roll back to a previous version 4.5.x in the binhex container? (No idea if that will fix the issue though but may be worth a shot).