3 hours ago, td00 said:

My assumption is that the VPN times out due to inactivity (in my case PIA) and the the container then fires a script to try and reconnect again but can't due to this error: "rtorrent: Error in option file: ~/.rtorrent.rc:134: Could not prepare socket for listening: Address already in use"

can you attach /config/rtorrent/config/rtorrent.rc here please.

12 minutes ago, binhex said:

can you attach /config/rtorrent/config/rtorrent.rc here please.

Yes sir it's right here: https://paste.ee/p/URgBB

Thanks much for the help!

23 minutes ago, td00 said:

Yes sir it's right here: https://paste.ee/p/URgBB

Thanks much for the help!

ok i dont see anything wrong there, so i can only assume the code i have in place to wait for the process to not exist is too efficient and i need further checks to make sure the port is also closed before starting rtorrent again, i will take a look at the code and let you know once a fix is in place.

4 hours ago, binhex said:

ok i dont see anything wrong there, so i can only assume the code i have in place to wait for the process to not exist is too efficient and i need further checks to make sure the port is also closed before starting rtorrent again, i will take a look at the code and let you know once a fix is in place.

Thanks binhex! Glad to know its not me Keep up the great work!

15 hours ago, binhex said:

inactivity timeout is a fact of life and isnt an issue by itself, this just indicates that openvpn has detected a ping timeout with the remote ip address, thus the tunnel is down, this can be caused by your isp and/or your vpn provider and can happen at any time and is completely normal. what isnt normal is having repeated timeouts which can indicate either an inability to create the vpn tunnel or an issue with your isp connection stability or vpn provider stability.

Understood. What is the timeout value? Can it be configured? and if not, can that be an enhancement?

15 hours ago, td00 said:

Thanks binhex! Glad to know its not me Keep up the great work!

the image has now been built with the additional port check, please pull down the new image.

5 hours ago, noski said:

Understood. What is the timeout value? Can it be configured? and if not, can that be an enhancement?

the default inactivity timeout is 0, which means do not timeout on inactivity, i believe what you are seeing is part of the --keepalive option, which can be tuned but really shouldnt need to be (works for everybody else), its currently set to ping every 10 secs, and if no response within 60 seconds then restart.

 

one thing i have noticed is that you are using a non standard port, and also using TCP, any particular reason for this?, it could be leading to the disconnections, taken from your log:-

remote ca-toronto.privateinternetaccess.com 1197

try changing the /config/openvpn/*.ovpn file 'remote' line to:-

 

remote ca-toronto.privateinternetaccess.com 1198 udp

save and then restart the container, see how you get on with that.

23 hours ago, binhex said:

the default inactivity timeout is 0, which means do not timeout on inactivity, i believe what you are seeing is part of the --keepalive option, which can be tuned but really shouldnt need to be (works for everybody else), its currently set to ping every 10 secs, and if no response within 60 seconds then restart.

 

one thing i have noticed is that you are using a non standard port, and also using TCP, any particular reason for this?, it could be leading to the disconnections, taken from your log:-

remote ca-toronto.privateinternetaccess.com 1197

try changing the /config/openvpn/*.ovpn file 'remote' line to:-

 

remote ca-toronto.privateinternetaccess.com 1198 udp

save and then restart the container, see how you get on with that.

Hey binhex,

 

OK I've pulled down your latest. However, this second tip here I went and looked in and found that the settings in my *.ovpn file seem to be indicating that it is in fact connecting with port 1198/udp: https://imgur.com/ge8Edhv

 

I will keep an eye on it though and report back if I find anything. Thanks again for all the help!

 

On 5/11/2019 at 10:18 PM, markomax said:

Privoxy has stopped working for me after pulling the latest version of this. I usually use Privoxy with Sonarr/Radarr/Lidarr/Jackett but they no longer work when I use hostname: localhost and port: 8118. I noticed that there were some new settings for RPC2 and RPC2_AUTH.  Is there some sort of username and password required for Privoxy too now?

 

On 5/12/2019 at 6:10 AM, binhex said:

Delete /config/privoxy/ folder and restart container

Sent from my EML-L29 using Tapatalk
 

When I delete the /config/privoxy folder, it does not re-create a new Privoxy folder when I relaunch rtorrent. I have Privoxy enabled in my run command. This is the only line related to privoxy in the log file when I launch: "[info] Privoxy not running".

 

If I move/delete all of my config folders except for openvpn and run it again, it will connect to privoxy only that one time. Once I move my (rather large) session folder and the rtorrent.rc file back over, Privoxy no longer works. Any ideas?

Privoxy will not start any other time.rtf Privoxy launched successfully.rtf

On 9/17/2019 at 2:22 AM, binhex said:

the default inactivity timeout is 0, which means do not timeout on inactivity, i believe what you are seeing is part of the --keepalive option, which can be tuned but really shouldnt need to be (works for everybody else), its currently set to ping every 10 secs, and if no response within 60 seconds then restart.

Thanks for that. I will play with the VPN_OPTIONS.

 

Quote

one thing i have noticed is that you are using a non standard port, and also using TCP, any particular reason for this?

I was using the 'STRONG' PIA config files which use port 1197 (https://www.privateinternetaccess.com/helpdesk/kb/articles/where-can-i-find-your-ovpn-files). I used the files directly from PIA without modification. I will try different ones to see if it helps.

Hey binhex,

 

So everything is running now but it seems now I'm getting Tracker: [Failed binding local connection end] on all my torrents after it refreshes the connection to VPN? I've pasted the log file here at the time it reconnected: https://paste.ee/p/yB9Yr

 

I was searching around Google to see if I could figure it out myself but to no avail lol. The only thing I found that came close had to do with Transmission and how it used (or didn't use) IPv6 bindings in its curl scripts. Doubt it will help but just in case: https://github.com/transmission/transmission/issues/88

 

 

Hey binhex,

 

One more question. It appears that your image comes coupled with rtcontrol which is great. I'm trying to run the following,

rtcontrol is_complete=yes is_open=yes seedtime=+3d

and it should return like 2000 results but I instead get:

 

INFO     Dumped 0 out of 2001 torrents.
INFO     Total time: 0.073 seconds.

 

Just wondering if you're using some special version or something or if I'm getting this code wrong?

 

I haven't had an "Inactivity timeout" for issue for a few days now. I don't know what the cause was but it appears to have fixed itself. I can only suspect some issue, as binhex suggested - with the VPN provider (PIA) or my Internet provider.

Thanks.

On 9/18/2019 at 3:08 PM, td00 said:

So everything is running now but it seems now I'm getting Tracker: [Failed binding local connection end] on all my torrents after it refreshes the connection to VPN?

so this should be automatically sorted for you, there is a delay of up to 30 seconds and a restart of rtorrent is required to re-configure, but this should be then re-defining the bind ip  for rtorrent to the newly allocated vpn ip, in my experience this works for me, can you attach your supervisord.log file, see here for instructions:-

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

 

9 hours ago, td00 said:

Just wondering if you're using some special version or something or if I'm getting this code wrong?

no idea im afraid, i can confirm its not a special version though.

15 hours ago, binhex said:

so this should be automatically sorted for you, there is a delay of up to 30 seconds and a restart of rtorrent is required to re-configure, but this should be then re-defining the bind ip  for rtorrent to the newly allocated vpn ip, in my experience this works for me, can you attach your supervisord.log file, see here for instructions:-

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

 

Hey binhex,

 

Ok I followed the directions and have my supervisord.log file for your review here: https://paste.ee/p/hegZp

The only issue is that in following those directions, I had to restart the container in order to turn on the DEBUG mode per your request. Normally not a big deal however, restarting the container always fixes the Tracker: [Failed binding local connection end] error so I'm afraid you're most likely going to see a normal looking supervisord.log file. This seems to happen sporadically (usually after several hours of being up but typically within the 24-48hr range) where I'll check the web ui and notice all my torrents in red with this message for each of them. It isn't until I restart the container that it comes back working perfectly fine.

Hey binhex,
 
Ok I followed the directions and have my supervisord.log file for your review here: https://paste.ee/p/hegZp
The only issue is that in following those directions, I had to restart the container in order to turn on the DEBUG mode per your request. Normally not a big deal however, restarting the container always fixes the Tracker: [Failed binding local connection end] error so I'm afraid you're most likely going to see a normal looking supervisord.log file. This seems to happen sporadically (usually after several hours of being up but typically within the 24-48hr range) where I'll check the web ui and notice all my torrents in red with this message for each of them. It isn't until I restart the container that it comes back working perfectly fine.

Ok I understand, well now debug is on we can wait for it to happen again, when it does please attach the current supervisord.log, hopefully they will tell me what's going on.

Sent from my CLT-L09 using Tapatalk

Hey binhex,

 

Ok, it's been a few days and unfortunately I've been away for a few days so I cannot tell you exactly what day it might have happened - but it did happen again ( Tracker: [Failed binding local connection end] error) and I've captured the logs starting from the day after the previous log post here: https://paste.ee/p/hpBU4

 

Here's hoping you can see what's up in these logs... keep up the great work and let me know if you need anything else from me.

Another update, one day passed since I rebooted to get everything working again and when I logged in... same issue.

 

*Edit - Sept/30th/2019* OK so this is happening now every few hours.

Edited September 30, 20196 yr by td00

On 9/18/2019 at 12:01 AM, markomax said:

 

 

When I delete the /config/privoxy folder, it does not re-create a new Privoxy folder when I relaunch rtorrent. I have Privoxy enabled in my run command. This is the only line related to privoxy in the log file when I launch: "[info] Privoxy not running".

 

If I move/delete all of my config folders except for openvpn and run it again, it will connect to privoxy only that one time. Once I move my (rather large) session folder and the rtorrent.rc file back over, Privoxy no longer works. Any ideas?

Privoxy will not start any other time.rtf 17.36 kB · 2 downloads Privoxy launched successfully.rtf 20.31 kB · 1 download

I still cannot get Privoxy working. Any ideas?

On 9/18/2019 at 5:01 AM, markomax said:

when I use hostname: localhost and port: 8118.

localhost will not work, you need to use the ip address of your unraid host, localhost will resolve to the hostname of the container NOT the host (as in unraid).

15 hours ago, markomax said:

I still cannot get Privoxy working. Any ideas?

are you sure your lan network is configured correctly?, from your log it is currently set to:-

LAN_NETWORK defined as '192.168.1.0/24'

if you arent sure how to set it then see Q4 from the following link:-

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

On 9/30/2019 at 5:28 AM, binhex said:

are you sure your lan network is configured correctly?, from your log it is currently set to:-

LAN_NETWORK defined as '192.168.1.0/24'

if you arent sure how to set it then see Q4 from the following link:-

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

Yes my LAN matches exactly with what is shown in the example. Privoxy will load up and connect if I launch the container with an empty session folder under /config/rtorrent/session, but as soon as I move all of the .rtorrent files etc back to the session folder and relaunch, it doesn't work. There are close to 4000 torrents total.. maybe that is just too many?

15 hours ago, markomax said:

Yes my LAN matches exactly with what is shown in the example. Privoxy will load up and connect if I launch the container with an empty session folder under /config/rtorrent/session, but as soon as I move all of the .rtorrent files etc back to the session folder and relaunch, it doesn't work. There are close to 4000 torrents total.. maybe that is just too many?

due to the fact you are not seeing the /config/privoxy folder being re-created it could be permissions, can you check that the following uid and gid have sufficient permissions to wherever you have defined /config on the host, taken from your log:-

 

2019-09-17 23:35:27.568036 [info] PUID defined as '1026'
2019-09-17 23:35:27.636838 [info] PGID defined as '101'

i have just done some basic tests here and found no issue whatsoever with privoxy when running using this image, i have deleted the config files and they get re-created, i have stopped and started the container multiple times and each time privoxy comes up ok, if i delete the /config/privoxy folder it gets re-created, so its got to be a bad config somewhere.

 

one other thing to note is that your umask is set to 002, now this SHOULD be ok, but you could try setting it to 000 to see if this makes a difference (if its not a uid/gid issue)

On 10/3/2019 at 12:54 PM, binhex said:

due to the fact you are not seeing the /config/privoxy folder being re-created it could be permissions, can you check that the following uid and gid have sufficient permissions to wherever you have defined /config on the host, taken from your log:-

 

2019-09-17 23:35:27.568036 [info] PUID defined as '1026'
2019-09-17 23:35:27.636838 [info] PGID defined as '101'

i have just done some basic tests here and found no issue whatsoever with privoxy when running using this image, i have deleted the config files and they get re-created, i have stopped and started the container multiple times and each time privoxy comes up ok, if i delete the /config/privoxy folder it gets re-created, so its got to be a bad config somewhere.

 

one other thing to note is that your umask is set to 002, now this SHOULD be ok, but you could try setting it to 000 to see if this makes a difference (if its not a uid/gid issue)

I had Privoxy working for about a week by launching fresh without any files in the session folder, then loading (and rechecking) all of the torrents from a watched directory.  For some reason, the Privoxy folder is only created the first time I launch with no other files in the config folder except those created by running the image. As soon as I restarted it, I see no other message in the log except for "[info] Privoxy not running" exactly like the second log I uploaded.

 

I agree it is likely a permissions thing that I don't understand how to fix. The permissions seem correct when I look at users, groups and the shared folder on my Synology DSM. If I am to troubleshoot this by trying a run command with a different umask, user, or group, do I need to delete the "perms.txt" file in the config folder before running everything again?