Jump to content
binhex

[Support] binhex - qBittorrentVPN

625 posts in this topic Last Reply

Recommended Posts

I'm currently using this docker with Mullvad VPN. Everything seems to be working fine, but how can I check that all of the traffic is truly going through the VPN for this Docker? I have VPN_ENABLED set to yes, and I have my Mullvad ID in VPN_USER and VPN_PASS, and then I have VPN_PROV set to custom. I've had a few terabytes incoming and outgoing, and haven't been throttled or warned yet, so I'm guessing that it's working, but I just want to be absolutely sure that all of that traffic is going through Mullvad.

 

Any tips are appreciated, thanks!!

Share this post


Link to post
Posted (edited)

  

1 hour ago, chrisp1992 said:

I'm currently using this docker with Mullvad VPN. Everything seems to be working fine, but how can I check that all of the traffic is truly going through the VPN for this Docker? I have VPN_ENABLED set to yes, and I have my Mullvad ID in VPN_USER and VPN_PASS, and then I have VPN_PROV set to custom. I've had a few terabytes incoming and outgoing, and haven't been throttled or warned yet, so I'm guessing that it's working, but I just want to be absolutely sure that all of that traffic is going through Mullvad.

 

Any tips are appreciated, thanks!!

 

If your vpn connection fails nothing else is started, once your vpn connection is up it starts rest of the applications, it's designed that way.

Edited by Jaska

Share this post


Link to post
23 hours ago, chrisp1992 said:

I'm currently using this docker with Mullvad VPN. Everything seems to be working fine, but how can I check that all of the traffic is truly going through the VPN for this Docker? I have VPN_ENABLED set to yes, and I have my Mullvad ID in VPN_USER and VPN_PASS, and then I have VPN_PROV set to custom. I've had a few terabytes incoming and outgoing, and haven't been throttled or warned yet, so I'm guessing that it's working, but I just want to be absolutely sure that all of that traffic is going through Mullvad.

 

Any tips are appreciated, thanks!!

Try the Torrent Address detection on https://ipleak.net/.

Share this post


Link to post

It looks like the Privoxy component of this is not working with the latest 4.2.2. update.  I have many containers that are now failing searches (sonarr, radarr, jackett) because I am using the http proxy through this container. 

The only real clue I can see is in the logs below, but I am not sure if this is related or not:

 

2020-03-29 17:43:40,645 DEBG 'start-script' stdout output:
Sun Mar 29 17:43:40 2020 ERROR: Linux route add command failed: external program exited with error status: 2

 

Share this post


Link to post
Posted (edited)
3 hours ago, guythnick said:

It looks like the Privoxy component of this is not working with the latest 4.2.2. update.  I have many containers that are now failing searches (sonarr, radarr, jackett) because I am using the http proxy through this container. 

The only real clue I can see is in the logs below, but I am not sure if this is related or not:

 


2020-03-29 17:43:40,645 DEBG 'start-script' stdout output:
Sun Mar 29 17:43:40 2020 ERROR: Linux route add command failed: external program exited with error status: 2

 

Same issue here.  I reverted to the 4.2.1-1-05 tag for now.

Edited by ksarnelli

Share this post


Link to post
10 hours ago, guythnick said:

It looks like the Privoxy component of this is not working with the latest 4.2.2. update.  I have many containers that are now failing searches (sonarr, radarr, jackett) because I am using the http proxy through this container. 

The only real clue I can see is in the logs below, but I am not sure if this is related or not:

 


2020-03-29 17:43:40,645 DEBG 'start-script' stdout output:
Sun Mar 29 17:43:40 2020 ERROR: Linux route add command failed: external program exited with error status: 2

 

please can you do the following:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

 

also could you attach the file /config/privoxy/config

Share this post


Link to post
8 hours ago, LakersFan said:

Same here. How did you revert back to 4.2.1-1-05?

Bring up the edit page for the container and change the repository from "binhex/arch-qbittorrentvpn" to "binhex/arch-qbittorrentvpn:4.2.1-1-05". By default the "latest" tag is pulled unless you specify a tag in the repository field.

Share this post


Link to post
8 minutes ago, guythnick said:

 

Here are both files when I run the latest image.  I also reverted to binhex/arch-qbittorrentvpn:4.2.1-1-05 and it is working normally.

 

supervisord.log 66.44 kB · 0 downloads config 72.29 kB · 0 downloads

your system looks to be running out of memory:-

pgrep: cannot allocate 4611686018427387903 bytes

which is probably leading to multiple failures during startup, i would doubt the issue is related, probably rolling back and starting was a coincidence - check your system for free memory.

Share this post


Link to post
15 minutes ago, binhex said:

your system looks to be running out of memory:-


pgrep: cannot allocate 4611686018427387903 bytes

 

I don't think he's running out of memory. Isn't it more likely that whatever is trying to allocate 4 exabytes is doing something wrong?

Share this post


Link to post
14 minutes ago, gcb922@yahoo.com said:

I don't think he's running out of memory. Isn't it more likely that whatever is trying to allocate 4 exabytes is doing something wrong?

possibly, or the app is just spitting out a rogue number cos its unable to allocate enough memory to process the request correctly - im able to replicate so i will take a look tonight, for now rollback.

Share this post


Link to post
Posted (edited)
1 hour ago, gcb922@yahoo.com said:

I don't think he's running out of memory. Isn't it more likely that whatever is trying to allocate 4 exabytes is doing something wrong?

Dumb question, how do you rollback?

 

I just upgraded my image this morning and am experiencing the same issue and don't believe I'm running out of memory.

 

2020-03-30 10:40:51,514 DEBG 'watchdog-script' stderr output:
pgrep: cannot allocate 4611686018427387903 bytes

2020-03-30 10:40:52,516 DEBG 'watchdog-script' stderr output:
pgrep: cannot allocate 4611686018427387903 bytes

 

Edited by Carlos Talbot

Share this post


Link to post

One thing I noticed with the newest build is that the container was having issues with DNS.  The log repeatedly said it couldn't resolve www.google.com. I reverted to the previous build and it is working as normal.

Share this post


Link to post
1 hour ago, binhex said:

ive found the issue, looks to be triggered when the stack size is set to unlimited:-

https://gitlab.com/procps-ng/procps/issues/152

 

so ive got a workaround for this, will test and if good then will release.

Just updated to the latest branch a few minutes ago and confirmed this fixed this recent pgrep: cannot allocate 4611686018427387903 bytes issue for me.
Thank you for correcting this so quickly and all the hard work you do for us @binhex

Share this post


Link to post
3 hours ago, intertet said:

Just updated to the latest branch a few minutes ago and confirmed this fixed this recent pgrep: cannot allocate 4611686018427387903 bytes issue for me.
Thank you for correcting this so quickly and all the hard work you do for us @binhex

+1 from me - I know most of the time you guys hear about what isn't working. @binhex your work is a key part of my homelab / selfhosted setup, thank you.

Share this post


Link to post
Posted (edited)

I noticed that my qBittorrent web UI was down so I came to this thread and saw the discussion regarding the "cannot allocate 4611686018427387903 bytes" issue.

I tailed the containers logs and sure enough, that is what I was seeing.

2020-03-30 20:49:11,570 DEBG 'start-script' stderr output:
pgrep: cannot allocate 4611686018427387903 bytes

I upgraded to the latest which fixed the "cannot allocate 4611686018427387903 bytes" issue.

However the container is still failing to start.

This is what I am seeing at in the logs currently.

2020-03-30 21:13:47,329 DEBG 'start-script' stdout output:
[info] Attempting to curl http://209.222.18.222:2000/?client_id=adb8c2b559fdde17f847119ecdeb1c8fda5b852953313e0488ef16f2bdb45a52...

2020-03-30 21:13:47,429 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 56 from curl != 0
[info] 12 retries left
[info] Retrying in 10 secs...

...

2020-03-30 21:15:38,565 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 56 from curl != 0
[info] 1 retries left
[info] Retrying in 10 secs...

2020-03-30 21:15:48,670 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx, exhausted retries exiting script...

2020-03-30 21:15:48,670 DEBG 'start-script' stdout output:
[warn] PIA VPN port assignment API currently down, terminating OpenVPN process to force retry for incoming port...

 

Google tells me that code 56 is known to occur when the network adapter has a conflict with the third-party VPN installed on your system.

I would really appreciate any insight as to why the adapter has a conflict with the third-party VPN and what I may be able to do as a workaround. 

I also tried deleting the image and reinstalling the container, same issue.

Edited by chancedonmillion

Share this post


Link to post
6 hours ago, psycho_asylum said:

Coincidentally, this also fixed the DNS error I was getting. Not sure if related, but hey.

I'm still having dns problems.

sh-5.0# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=10.3 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.334/10.711/11.088/0.377 ms
sh-5.0# ping google.com
ping: google.com: Temporary failure in name resolution
sh-5.0# 

 

Share this post


Link to post
9 minutes ago, mr007 said:

I'm still having dns problems.


sh-5.0# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=10.3 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.334/10.711/11.088/0.377 ms
sh-5.0# ping google.com
ping: google.com: Temporary failure in name resolution
sh-5.0# 

 

likewise

sh-5.0# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=26.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=26.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=25.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=25.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=26.1 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 25.713/25.957/26.145/0.147 ms
sh-5.0# ping goolge.com
ping: goolge.com: Temporary failure in name resolution

 

Share this post


Link to post
3 hours ago, chancedonmillion said:

I noticed that my qBittorrent web UI was down so I came to this thread and saw the discussion regarding the "cannot allocate 4611686018427387903 bytes" issue.

I tailed the containers logs and sure enough, that is what I was seeing.


2020-03-30 20:49:11,570 DEBG 'start-script' stderr output:
pgrep: cannot allocate 4611686018427387903 bytes

I upgraded to the latest which fixed the "cannot allocate 4611686018427387903 bytes" issue.

However the container is still failing to start.

This is what I am seeing at in the logs currently.


2020-03-30 21:13:47,329 DEBG 'start-script' stdout output:
[info] Attempting to curl http://209.222.18.222:2000/?client_id=adb8c2b559fdde17f847119ecdeb1c8fda5b852953313e0488ef16f2bdb45a52...

2020-03-30 21:13:47,429 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 56 from curl != 0
[info] 12 retries left
[info] Retrying in 10 secs...

...

2020-03-30 21:15:38,565 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 56 from curl != 0
[info] 1 retries left
[info] Retrying in 10 secs...

2020-03-30 21:15:48,670 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx, exhausted retries exiting script...

2020-03-30 21:15:48,670 DEBG 'start-script' stdout output:
[warn] PIA VPN port assignment API currently down, terminating OpenVPN process to force retry for incoming port...

 

Google tells me that code 56 is known to occur when the network adapter has a conflict with the third-party VPN installed on your system.

I would really appreciate any insight as to why the adapter has a conflict with the third-party VPN and what I may be able to do as a workaround. 

I also tried deleting the image and reinstalling the container, same issue.

I'm having the same issue. I downgraded to 4.2.1-1-05 but I'm still getting the errors messages you listed above.

Share this post


Link to post
4 hours ago, chancedonmillion said:

I noticed that my qBittorrent web UI was down so I came to this thread and saw the discussion regarding the "cannot allocate 4611686018427387903 bytes" issue.

I tailed the containers logs and sure enough, that is what I was seeing.


2020-03-30 20:49:11,570 DEBG 'start-script' stderr output:
pgrep: cannot allocate 4611686018427387903 bytes

I upgraded to the latest which fixed the "cannot allocate 4611686018427387903 bytes" issue.

However the container is still failing to start.

This is what I am seeing at in the logs currently.


2020-03-30 21:13:47,329 DEBG 'start-script' stdout output:
[info] Attempting to curl http://209.222.18.222:2000/?client_id=adb8c2b559fdde17f847119ecdeb1c8fda5b852953313e0488ef16f2bdb45a52...

2020-03-30 21:13:47,429 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 56 from curl != 0
[info] 12 retries left
[info] Retrying in 10 secs...

...

2020-03-30 21:15:38,565 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx
[warn] Exit code 56 from curl != 0
[info] 1 retries left
[info] Retrying in 10 secs...

2020-03-30 21:15:48,670 DEBG 'start-script' stdout output:
[warn] Response code 000 from curl != 2xx, exhausted retries exiting script...

2020-03-30 21:15:48,670 DEBG 'start-script' stdout output:
[warn] PIA VPN port assignment API currently down, terminating OpenVPN process to force retry for incoming port...

 

Google tells me that code 56 is known to occur when the network adapter has a conflict with the third-party VPN installed on your system.

I would really appreciate any insight as to why the adapter has a conflict with the third-party VPN and what I may be able to do as a workaround. 

I also tried deleting the image and reinstalling the container, same issue.

I am getting the same thing. Not sure if it is the container or on pia's side. if you change STRICT_PORT_FORWARD to no in the docker settings it should get you back running.

Share this post


Link to post
Posted (edited)

Terrible timing, I only just set it up yesterday after trying many many options (all vpn's suck for torrents it seems) 

And also getting the curl response code mismatch error

 

 

Thanks Binhex, I thought it might be PIA's end! 

Edited by Snubbers

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.