Rinzler
-
Posts
18 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Rinzler
-
-
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.
- 1
-
6 hours ago, TrCl said:
Yeah, thanks. I think maybe it's the kernel version I'm on that's the issue. I'm running on a NAS that I believe is running version 4.14. Perhaps that's the problem.
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!
- 1
-
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), restartingWed 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? -
Quote
2019/07/30 18:42:26 [emerg] 790#790: open() "/etc/nginx/nginx.conf" failed (13: Permission denied) 2019-07-30 18:42:26,598 DEBG fd 22 closed, stopped monitoring <POutputDispatcher at 139790208692176 for <Subprocess at 139790208690944 with name rutorrent-script in state RUNNING> (stdout)> 2019-07-30 18:42:26,599 DEBG fd 26 closed, stopped monitoring <POutputDispatcher at 139790208774328 for <Subprocess at 139790208690944 with name rutorrent-script in state RUNNING> (stderr)> 2019-07-30 18:42:26,599 INFO exited: rutorrent-script (exit status 1; not expected) 2019-07-30 18:42:26,599 DEBG received SIGCHLD indicating a child quit 2019-07-30 18:42:27,229 DEBG 'watchdog-script' stdout output:
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.
- 1
-
Looks like rakshasa pushed rtorrent .98! Thanks for your continued efforts, Binhex, this container is great work.
-
1 hour ago, cirialkilr said:
Most recent update broke my setup.
...
Same here
-
Thanks, all good!
- 1
-
I am on :latest and I just recently started getting a Cfscrape (cloudflare plugin) warning which forces the plugin disabled, every time I visit the rutorrent GUI. Any idea if I need this plugin and how to disable it, in the meantime?
Thanks!
Raven
[Support] binhex - PrivoxyVPN
in Docker Containers
Posted · Edited by 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.