Rinzler

Thanks for the extensive documentation, it's really useful. Anyone have experience on what happens if you have a watchtower container that tries to update this container (arch-privoxyvpn's) when a different (e.g. jackett) depends on this one network through e.g. --network=container:arch-privoxyvpn? According to your document the order matters, but does that lead to IP leakage if WT tries to update it; or does it even fix itself after doing it? Looking for best practices; hoping watchtower doesn't need to be nixed since I do have lots of containers it works well with.

Thanks @binhex , for everything, as always You are the best. It's fully working with all :latest now. 🚀

I also have the same exact issue currently as above. After a rollback to aforementioned version, it works. Also rolled back prixovy images too, since those also weren't working.

I am not able to see the privoxy logs in any way when enabled; I might be doing something wrong, but I checked the logfile, it's 0 bytes. Seems the aggregated log doesn't include the privoxy log like the privoxy containers. I tried debug=true and same results. Any ideas? Thanks!

Thanks @binhex . Updated kernel and it was good to go.

I'm also seeing this on a debian 10

Realize this isn't PIA thread or subreddit, but the options seem to be dropping like flies. Just lost a netherlands earlier too. Time for a new VPN? anyone know what is going on and if they're going to fix this mess?

Regarding the endpoints, is it possible that this is similar to a hostname issue that happened with nyc one a few weeks back? The image was stable until it was restarted, so I'm almost positive it's a DNS issue. If it's a DNS issue, if we knew the european locations IP addresses?, could we modify the config file to use that instead of the hostname? That being said; spain.privateinternetaccess.com for example does resolve to a ping, so maybe it's not that. For now I guess everyone is on Canada.

Thanks. That's very helpful, and it works!

I'm not sure what changed but in the last 2 days, my PIA NYC privoxy image stopped being able to run. It was running for nearly 7 months straight, so I rolled the image back a few months thinking that would help - but it doesn't. It seems to get to the point where "OpenVPN" started" then after that, and before even trying to start Privoxy: Wed Jul 15 07:11:26 2020 [UNDEF] Inactivity timeout (--ping-restart), restarting Wed Jul 15 07:12:31 2020 SIGHUP[soft,ping-restart] received, process restarting and keeps going in a loop where it repeats that. I've seen previously it probably is supposed to bind the it the network stack at this point, but I guess it's timing out? Worth noting the other instance, which is on another image (coupled with rtorrent) works fine still, tho that one is in connecting to a Spain host. At any rate, I reloaded the OpenVPN files thinking it might be a cert issue, but no luck there. I went through config changes to set the new env variables but that changed nothing at all. Any ideas? thanks!

At least 20% of the time a download completes, it errors, returns to 0% and says "Download Registers as unfinished Chunks".. kind of like here: https://github.com/rakshasa/rtorrent/issues/438 Anyone else have success tackling this issue? My max open files is 256. It seems we're out of date (there's a .98 https://github.com/rakshasa/rtorrent/releases ) Any ideas?

Based on these lines, I kind of suspect it can't read /etc/nginx/nginx.conf ... not sure if this is the only problem you have but "[emerg]" doesn't sound great. If I'm right, rTorrent can't connect to ruTorrent which runs on that failed nginx server. A gut suspicion is likely due settings on your NAS versus your run parameters with : -e UMASK=000 \ -e PUID=1029 \ -e PGID=100 \ You could try as terminal on nas: cd /volume1/docker/rutorrent/nginx/config ls -l to see permissions group id, and owner of the nginx.conf file. It should match your arguments, and if it doesn't you can change its owner like so: sudo chown 1029:100 nginx.conf then maybe try expand it's permissions, to something less secure but more flexible 755 sudo chmod 755 nginx.conf Good luck.

Looks like rakshasa pushed rtorrent .98! Thanks for your continued efforts, Binhex, this container is great work.

Same here

Thanks, all good!