Jump to content
binhex

[Support] binhex - rTorrentVPN

1752 posts in this topic Last Reply

Recommended Posts

On 9/14/2019 at 6:34 AM, noski said:

For me, I can find "Inactivity timeout" entries in my supervisord logs going back as far as June 2018, possibly further, but the logs have rolled. So this is not a 'new' issue.

It was infrequent in the past, so I guess it went unnoticed. Currently, it is constant.

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.

Share this post


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

Share this post


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

Share this post


Link to post
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!

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
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!

Share this post


Link to post

 

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

Share this post


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

Share this post


Link to post

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

 

 

Share this post


Link to post

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?

 

Share this post


Link to post

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.

Share this post


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

 

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post

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.

Share this post


Link to post

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 by td00

Share this post


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

Share this post


Link to post
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).

Share this post


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

Share this post


Link to post

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.