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

 

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 March 30, 20206 yr by ksarnelli

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

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

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.

Quote

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

 

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 config

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.

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?

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.

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 March 30, 20206 yr by Carlos Talbot

22 minutes ago, Carlos Talbot said:

Dumb question, how do you rollback?

Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

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.

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.

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

2 hours 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.

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

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.

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 March 31, 20206 yr by chancedonmillion

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# 

 

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

 

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.

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.

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 March 31, 20206 yr by Snubbers

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

There's a better option - it appears this issue only affects Canadian servers. You can switch to another country with servers that support port forwarding, Germany for example.

So I am having trouble with speeds in qbittorrent as well. I know the documentation says that if we aren't using PIA we have to manually set up port forwarding for the VPN provider we are using. I have Nord (I guess they don't have allow port forwarding), but the rest of the container seems to work great alongside privoxy for web traffic and other container proxies (sonarr, radarr, etc.). 

 

Does anyone know if top speeds will be possible with this setup and Nord, or am I outta luck on that?