[Support] binhex - qBittorrentVPN


Recommended Posts

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/.

Link to comment

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

 

Link to comment
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
Link to comment
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

Link to comment
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.

  • Thanks 1
Link to comment
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.

Link to comment
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?

Link to comment
14 minutes ago, [email protected] 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.

Link to comment
1 hour ago, [email protected] 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
Link to comment
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

  • Like 1
Link to comment
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.

Link to comment

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
Link to comment
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# 

 

Link to comment
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

 

Link to comment
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.

Link to comment
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.

Link to comment

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
Link to comment
4 hours ago, binhex said:

 

if you use pia and you are seeing the above in your log then the issue is that the pia api is down, looks like they are having technical difficulties right now, see here:-

https://www.reddit.com/r/PrivateInternetAccess/comments/fs7ja0/cant_get_forwarded_port/

 

For now your only option is to set STRICT_PORT_FORWARD to 'no', this will allow you to connect but you will NOT have a working incoming port, so speeds will be slow at best.

 

Just to be clear, there is nothing i can do about this guys, its a vpn provider issue.

Thanks for update, set the value to "no" and can now open the gui again. Only getting around 8MB/s down but better than nothing

Link to comment

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.