Jump to content
binhex

[Support] binhex - rTorrentVPN

2003 posts in this topic Last Reply

Recommended Posts

On 10/23/2019 at 11:47 PM, mbc0 said:

Hi! 

 

I just swapped last week from your deluge vpn to this rtorrent vpn and it has been much better for me (extra features & performance) however today (since rc3 update) I am getting dog slow performance! don't know if it is related or not but no matter what browser I use it takes minutes to respond and constant timeouts, any ideas?  I am using a Threadripper with 40GB free ram and barely a tickle on the cores

 

2019-10-23 23:00:33,957 DEBG 'watchdog-script' stdout output:
[info] rTorrent running
[info] Initialising ruTorrent plugins (checking nginx is running)...

2019-10-23 23:00:33,965 DEBG 'watchdog-script' stdout output:
[info] nginx running
[info] Initialising ruTorrent plugins...

2019-10-23 23:00:34,010 DEBG 'watchdog-script' stdout output:


2019-10-23 23:00:34,032 DEBG 'watchdog-script' stdout output:
[info] ruTorrent plugins initialised

2019-10-23 23:30:35,333 DEBG 'watchdog-script' stdout output:
[info] Attempting to curl https://portchecker.co/check...

2019-10-23 23:30:36,398 DEBG 'watchdog-script' stdout output:
[info] Curl successful for https://portchecker.co/check, response code 200

2019-10-23 23:33:15,522 DEBG 'rutorrent-script' stderr output:
2019/10/23 23:33:15 [error] 1214#1214: *1859 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.17.0.1, server: localhost, request: "POST /RPC2 HTTP/1.1", upstream: "scgi://127.0.0.1:5000", host: "192.168.0.33:9080"

2019-10-23 23:35:45,549 DEBG 'rutorrent-script' stderr output:
2019/10/23 23:35:45 [error] 1214#1214: *1894 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.17.0.1, server: localhost, request: "POST /RPC2 HTTP/1.1", upstream: "scgi://127.0.0.1:5000", host: "192.168.0.33:9080"
 

Hi @binhex sorry to nag but wonder if you have any ideas what could cause these performance issues?  it becomes unusable, lidarr, radarr, sonarr all lose connection to this docker and the UI is too slow to use.  It seems to sort itself out after a while and may be ok for hours then it does it again.  As I stated earlier, I have masses of resources available so don't know where to start with diagnosis.  Never had any issues with your deluge docker but need the features of rtorrent.

 

Thanks

Share this post


Link to post
5 minutes ago, mbc0 said:

Hi @binhex sorry to nag but wonder if you have any ideas what could cause these performance issues?  it becomes unusable, lidarr, radarr, sonarr all lose connection to this docker and the UI is too slow to use.  It seems to sort itself out after a while and may be ok for hours then it does it again.  As I stated earlier, I have masses of resources available so don't know where to start with diagnosis.  Never had any issues with your deluge docker but need the features of rtorrent.

 

Thanks

are you still running unraid 6.8.0 rc3?, if so and the issue started with that version i think your first thing to try is to roll back to the previous version that worked. i myself run this image and have zero performance issues with it (running unraid 6.7.2), so im confident that its something to do with your setup.

Share this post


Link to post

Hi @binhex I am running 6.8.0-rc4 are there still performance issues on that version? sorry to bother you if it is nothing to do with your docker, I expect it is something to do with my config it's just that I run 20+ dockers and only have an issue with this one. 😞 

Share this post


Link to post
2 minutes ago, mbc0 said:

I am running 6.8.0-rc4 are there still performance issues on that version?

i have no idea, i stay away from release candidates unless i have an urgent issue to resolve with the stable version, as your issue started with rc3 i would suspect that, but its only a guess.

Share this post


Link to post

ok, I will switch back to deluge until I am out of the RC, I only moved to the RC due to disk speed issues which have now been resolved for me (1st time I have used an RC release) 

 

Thanks for your time

Share this post


Link to post

First off thank you for a great docker image..

QQ... I want to add a new tracker file to my autodl setup.  Where should I place the file in order for it to be recognized by autodl?  I was thinking /mnt/user/appdata/binhex-rtorrentvpn/autodl/*****.tracker but that didn't appear to work.

 

Thanks.

  

Share this post


Link to post

I've noticed over the past week or so that some of my stuff has loaded into rTorrent, but was not starting or doing anything. I finally figured out that sometimes, upon loading, the Priority is being automatically set to "Don't Download" and/or the Channel is set to "up256" (which also has 0 set for download, thus stalled). 

 

Is there anything that has changed that might cause this? Not sure if those settings come from rTorrent or ruTorrent. I don't remember setting those in my rtorrent.rc file ever (and not even sure you can if they are part of ruTorrent), and even so I haven't edited my .rc file in months but this has suddenly started happening only recently. Going into settings in ruTorrent, my channels I think are still default and the "Default Channel" option is set to "Don't Set" so it shouldn't be automatically selecting any channel, much less up256.

Share this post


Link to post
I've noticed over the past week or so that some of my stuff has loaded into rTorrent, but was not starting or doing anything. I finally figured out that sometimes, upon loading, the Priority is being automatically set to "Don't Download" and/or the Channel is set to "up256" (which also has 0 set for download, thus stalled). 
 
Is there anything that has changed that might cause this? Not sure if those settings come from rTorrent or ruTorrent. I don't remember setting those in my rtorrent.rc file ever (and not even sure you can if they are part of ruTorrent), and even so I haven't edited my .rc file in months but this has suddenly started happening only recently. Going into settings in ruTorrent, my channels I think are still default and the "Default Channel" option is set to "Don't Set" so it shouldn't be automatically selecting any channel, much less up256.
No change from me, the only thing I changed in tTorrent.rc was the addition of a commented out maximum size for a file in a torrent, that's it.

Sent from my CLT-L09 using Tapatalk

Share this post


Link to post
54 minutes ago, binhex said:

No change from me, the only thing I changed in tTorrent.rc was the addition of a commented out maximum size for a file in a torrent, that's it.

Sent from my CLT-L09 using Tapatalk
 

OK. Is there a way to clear/reset the ruTorrent settings without having to reload the entire container? A conf file(s) or folder(s) that I can just delete and will be recreated with defaults when I restart the container? Seems like maybe a stuck or old setting in there is messing things up.

 

Edit: Actually I do have some RSS saved in ruTorrent so I guess I don't want to delete the entire configuration. 

I see /config/rutorrent/share/settings/throttle.dat file which looks like it maybe relates to the channels. If I delete that will it recreate with defaults upon a restart?

 

Edit2: So I took a closer look at that throttle.dat file.

O:9:"rThrottle":3:{s:4:"hash";s:12:"throttle.dat";s:3:"thr";a:10:{i:0;a:3:{s:2:"up";i:64;s:4:"down";i:0;s:4:"name";s:4:"up32";}i:1;a:3:{s:2:"up";i:128;s:4:"down";i:0;s:4:"name";s:5:"up128";}i:2;a:3:{s:2:"up";i:64;s:4:"down";i:256;s:4:"name";s:11:"up64down256";}i:3;a:3:{s:2:"up";i:128;s:4:"down";i:1024;s:4:"name";s:13:"up128down1024";}i:4;a:3:{s:2:"up";i:256;s:4:"down";i:2048;s:4:"name";s:13:"up256down2048";}i:5;a:3:{s:2:"up";i:0;s:4:"down";i:16;s:4:"name";s:6:"down16";}i:6;a:3:{s:2:"up";i:0;s:4:"down";i:32;s:4:"name";s:6:"down32";}i:7;a:3:{s:2:"up";i:0;s:4:"down";i:64;s:4:"name";s:6:"down64";}i:8;a:3:{s:2:"up";i:0;s:4:"down";i:128;s:4:"name";s:7:"down128";}i:9;a:3:{s:2:"up";i:0;s:4:"down";i:256;s:4:"name";s:7:"down256";}}s:7:"default";i:5;}

Looking at this reminded me that I did play with channels a while back and setup some custom ones in the web GUI. I also played with setting a default channel, which was #5 at the time. I think when I restarted the container they just went back to defaults so I didn't bother with them anymore since they didn't seem to stick. Even though the ruTorrent GUI settings didn't show the above custom channels anymore and didn't seem to be using them either, it seems like it would occasionally use the default channel as #5 lately, which in the default channels is "up256". It looks like it would happen when Medusa was sending torrents/magnets over, maybe because it doesn't use the "admin" user but just a default of some kind via SCGI? Still doesn't explain the "Don't Download" priority being set sometimes, but maybe related somehow.

 

Anyway, I stopped the container, deleted the /config/rutorrent/share/settings/throttle.dat file, and started it up again. It didn't initially recreate the file. I logged into the ruTorrent web GUI as admin and made a change to the channels and then it created a file under /config/rutorrent/share/users/admin/settings/throttle.dat instead. Now that I know how it works I'll probably just delete that file anyway and leave it at defaults as I don't really use channels currently. Here's what that new default (except small change on one channel) file looks like:

O:9:"rThrottle":3:{s:4:"hash";s:12:"throttle.dat";s:3:"thr";a:10:{i:0;a:3:{s:2:"up";i:16;s:4:"down";i:0;s:4:"name";s:4:"up16";}i:1;a:3:{s:2:"up";i:32;s:4:"down";i:0;s:4:"name";s:4:"up32";}i:2;a:3:{s:2:"up";i:64;s:4:"down";i:0;s:4:"name";s:4:"up64";}i:3;a:3:{s:2:"up";i:128;s:4:"down";i:0;s:4:"name";s:5:"up128";}i:4;a:3:{s:2:"up";i:256;s:4:"down";i:1024;s:4:"name";s:5:"up256";}i:5;a:3:{s:2:"up";i:0;s:4:"down";i:16;s:4:"name";s:6:"down16";}i:6;a:3:{s:2:"up";i:0;s:4:"down";i:32;s:4:"name";s:6:"down32";}i:7;a:3:{s:2:"up";i:0;s:4:"down";i:64;s:4:"name";s:6:"down64";}i:8;a:3:{s:2:"up";i:0;s:4:"down";i:128;s:4:"name";s:7:"down128";}i:9;a:3:{s:2:"up";i:0;s:4:"down";i:256;s:4:"name";s:7:"down256";}}s:7:"default";i:0;}

If it continues doing weird stuff, I'll try to update here. Otherwise hopefully this will help somebody else if something similar happens to them.

Edited by deusxanime
research

Share this post


Link to post
On 10/22/2019 at 6:35 PM, binhex said:

Hi guys, so historically it has been difficult/impossible to change the listening port for rtorrent programmatically whilst its running, this lead to the only option which is to sigint rtorrent and change the port and then restart the process, this unfortunately can lead to situations where the process does not end nicely and thus rtorrent cannot be restarted.
 

Wind forward in time and this is now possible, however in order to do this we need to supply the credentials the authenticate with rtorrent before we can issues commands. As i don't know what each user has set their rpc2 and web ui passwords to (and i obviously shouldn't know this either!) then the only way for me to do this going forward is to allow the user to define the credentials for rpc2 and web ui as environment variables.
 

So from the next build if you have changed the username and password from the defaults (user admin, password rutorrent) then you will need to add in the following 'variables' :-
 


Key                 Value               Default         Description
RPC2_USER           <your username>     admin           sets the username for RPC2 auth
RPC2_PASS           <your passs>        rutorrent       sets the password for RPC2 auth
ENABLE_WEBUI_AUTH   yes/no              yes             sets web ui authentication for web ui (nginx) - if you are reverse proxying you probably want this set to no, otherwise yes.
WEBUI_USER          <your username>     admin           sets the username for web ui auth
WEBUI_PASS          <your passs>        rutorrent       sets the password for web ui auth

The above will result in a more stable rtorrent/rutorrent experience, whilst allowing us to maintain a working incoming port during all situations, i hope you agree a worthy improvement! (testing was a bitch).

 

Any questions please post them.

 

 

Hi @binhex, sorry that I'm kinda late to the party. The upgrade path wasn't totally smooth for me. I haven't noticed the new parameters, and since they have defaults (and also given that you've changed nginx.conf to read credentials from the new webui_auth file bypassing my custom settings) my container's rutorrent has been exposed to the internet with default credentials for a while.

Luckily I had

ENABLE_RPC2=no

Or it would have also exposed XML RPC over the internet with easily guessable default credentials. I guess I've shared the following article already, but it demonstrates why exposing RPC2 with no password or default credentials is not a good idea: https://www.f5.com/labs/articles/threat-intelligence/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

 

I know that ultimately this is a trade-off between security and convenience but given how many people are using your container I would suggest that you make it as secure as possible by default. I guess that two good ways to handle RPC_USER/RPC_PASS/WEBUI_USER/WEBUI_PASS without making the container vulnerable by default are:

 

1. Remove the mentioned variables. From inside the container you can probably issue XMLRPC commands straight to port 5000 or use a sgci_local socket (bypassing nginx authentication altogether) right? Otherwise, during container startup you can generate random credentials.

2. Keep the variables but fail to start the container if no values are provided. IMO, default credentials are a really bad idea. Of course that a simple docker inspect will reveal the passwords, but I guess that this is not a big issue given that VPN_PASS is already exposed (secrets are a better alternative but it is limited to docker swarm and docker-compose).

 

Cheers

Edited by Cat_Seeder

Share this post


Link to post

Im having constant issues with the docker bringing my server to a crawl. Im migrating from qbittorent and it seems like everything I do in rtorrent maxes out my CPU utilization on my server and locks up the server. I've had to force reboot twice already.

 

Simple things like deleting dead torrents that have been removed from trackers or force rechecking files so that I can get everything migrated is causing the server to be at 100% CPU most of the time. Ive never had this problem before installing this docker. 

 

In order to keep this from completely killing my server, I run operations on 5 torrents at a time and even still, I have issues with that.

 

Does anyone know what may be causing this? I'm going to have to disable this docker until I find out why this is happening.

 

 

53552108630b68b4f65c392f0262aede.png

Edited by DazedAndConfused

Share this post


Link to post
On 11/10/2019 at 3:43 AM, DazedAndConfused said:

Im having constant issues with the docker bringing my server to a crawl. Im migrating from qbittorent and it seems like everything I do in rtorrent maxes out my CPU utilization on my server and locks up the server. I've had to force reboot twice already.

 

Simple things like deleting dead torrents that have been removed from trackers or force rechecking files so that I can get everything migrated is causing the server to be at 100% CPU most of the time. Ive never had this problem before installing this docker. 

 

In order to keep this from completely killing my server, I run operations on 5 torrents at a time and even still, I have issues with that.

 

Does anyone know what may be causing this? I'm going to have to disable this docker until I find out why this is happening.

 

 

53552108630b68b4f65c392f0262aede.png

That's a weird one, maybe attach to the container and run `top` to understand what processes are using CPU Time. You can also limit the how many CPUs are available to the container with Docker's --cpu option (see https://docs.docker.com/config/containers/resource_constraints/ for further info). I've noticed that rutorrent may get stuck for a while when I delete large (as in 100GB+) torrents with data, other than that I normally seed a few thousand torrents with no issues (and nowhere near 100% CPU usage). 

Share this post


Link to post

Can someone give me some advice about how to handle rtorrent with use of the autotools move option? I changed rtorrent.rc with a folder to put new downloads in, and configured autotools to move torrents after they are completed. With the options "add torrent's label in path"  and "add torrent's name to path" enabled. This is working fine, torrents are downloaded to /data/torrents/incoming. And after there are done they get moved to /data/torrents/completed/{label name}/{torrent name}. Just the way i want it to, nice!

However, when i restart the rtorrentvpn docker, it "resets" all the save path's of all the torrents already done. While the data is still in the "completed" folder, rtorrent is looking in the "incomplete" folder and cannot find the data. This causes rtorrent to stop seeding which i do not want.

I already did some search on google and here on the forums, but i'm not yet on the right path to fix this problem. Anyone?

Share this post


Link to post

Ok, so i did give it some more try's today, but failed just the same. I really don't know where i'm going wrong here. I am pretty new with unraid and containers. Today i read this topic from page 40 to 72 in hope to get some more information, and i did the following after multiple tries.

- Deleted the container, image and the whole binhex-rtorrentvpn folder inside of appdata.
- Shutdown Docker in Unraid Settings, and started it all again after a minute or so. Just to be sure

- Did not start any other container while doing all of this
- Installed binhex-rtorrentvpn
- Started the container, open settings, only to change autotools. I did not do anything else!
- Downloaded a torrent, first it gets in incomplete, moves to completed once done, great

- Restarted the container trough Unraid Webgui

- And rtorrent again expects the file to be in incomplete, its not there, shows 0,0% and in paused state

Only setting i changed is the network type i guess in container settings. I have a Mullvad vpn setup on my pfSense, which filters some ip's and put them on vpn. But i did also try this whole process described above, and use the normal bridge mode. Also with the same result...

 

Still having the same problem... I added the log, settings, screenshot of rutorrent after the restart. Anyone who has a idea how to solve this?

rTorrent Settings.png

Container Settings.png

Almost forgot, as frustrating as this has been for the last 3-4 hours. A friend who also has a unraid server @ home with rtorrentvpn looked at my config. We were not able to compare the settings exactly this after noon, but he also did not see anything weird, while he is supposed to have the same settings. But again, even "out of the box" i have this problem. The other "rutorrent" plugin is working, but i rather use this one...

supervisord.log

rtorrent.rc

Edited by CellDweller
Almost forgot story...

Share this post


Link to post
On 11/3/2019 at 7:20 PM, Cat_Seeder said:

 

Hi @binhex, sorry that I'm kinda late to the party. The upgrade path wasn't totally smooth for me. I haven't noticed the new parameters, and since they have defaults (and also given that you've changed nginx.conf to read credentials from the new webui_auth file bypassing my custom settings) my container's rutorrent has been exposed to the internet with default credentials for a while.

Luckily I had


ENABLE_RPC2=no

Or it would have also exposed XML RPC over the internet with easily guessable default credentials. I guess I've shared the following article already, but it demonstrates why exposing RPC2 with no password or default credentials is not a good idea: https://www.f5.com/labs/articles/threat-intelligence/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

 

I know that ultimately this is a trade-off between security and convenience but given how many people are using your container I would suggest that you make it as secure as possible by default. I guess that two good ways to handle RPC_USER/RPC_PASS/WEBUI_USER/WEBUI_PASS without making the container vulnerable by default are:

 

1. Remove the mentioned variables. From inside the container you can probably issue XMLRPC commands straight to port 5000 or use a sgci_local socket (bypassing nginx authentication altogether) right? Otherwise, during container startup you can generate random credentials.

2. Keep the variables but fail to start the container if no values are provided. IMO, default credentials are a really bad idea. Of course that a simple docker inspect will reveal the passwords, but I guess that this is not a big issue given that VPN_PASS is already exposed (secrets are a better alternative but it is limited to docker swarm and docker-compose).

 

Cheers

 

I agree with removing default credentials. I ended up removing admin manually from my config file.

 

Also the edit to the readme file here: https://github.com/binhex/arch-rtorrentvpn/commit/487dac431e87fc67d8e0106217b20af1cfeba017#diff-04c6e90faac2675aa89e2176d2eec7d8

is confusing as you used <> for variable holders, which are normally inside of markdown code blocks (`), but in this case they are not. To the casual viewer, it looks like there is no username or password when viewing the readme, but in reality it's either the default or custom set creds.  I don't see the default mentioned in the readme either.

Perhaps change usage of <> to [] or more judicious use of code blocks?

Edited by jraid

Share this post


Link to post

Edit: I'm an idiot and forgot to download new openvpn configs...

 

 

Attemping to move from PIA to AirVPN but so far am unsuccessful. Any ideas what could be wrong. I changed

 

VPN_PROV to airvpn

Updated VPN_USER and VPN_PASS to the new credentials. Tested this on my local machine and am able to connect.

 

Is there something else I'm needing to change?

 

2019-11-22 13:46:26,534 DEBG 'start-script' stdout output:
Fri Nov 22 13:46:26 2019 WARNING: file 'credentials.conf' is group or others accessible

Fri Nov 22 13:46:26 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Fri Nov 22 13:46:26 2019 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10

2019-11-22 13:46:26,535 DEBG 'start-script' stdout output:
[info] OpenVPN restarted
Fri Nov 22 13:46:26 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2019-11-22 13:46:26,535 DEBG 'start-script' stdout output:
Fri Nov 22 13:46:26 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1198
Fri Nov 22 13:46:26 2019 UDP link local: (not bound)
Fri Nov 22 13:46:26 2019 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1198

2019-11-22 13:46:26,670 DEBG 'start-script' stdout output

 

Edited by Fiala06

Share this post


Link to post

Suddenly, I can't get the page to load in Chrome or IE. It's just a blank white page, no login. Works fine in FireFox. I cleared my cache as well.

Edited by bobbintb

Share this post


Link to post

Is there any way at all to attach to the running irssi process to be able to control it? 

Or to restart irssi without restarting the whole container?

 

It would be nice to start it on its own `screen` so we can attach to the process.

Share this post


Link to post
2 hours ago, Jeffarese said:

It would be nice to start it on its own `screen` so we can attach to the process.

thats exactly what it does do, apart from its not screen its tmux, session name is 'irssi_session' and window name is 'irssi_window'

Share this post


Link to post
13 minutes ago, binhex said:

thats exactly what it does do, apart from its not screen its tmux, session name is 'irssi_session' and window name is 'irssi_window'

I did `tmux ls` and it said that "no server running"

Share this post


Link to post
1 hour ago, Jeffarese said:

I did `tmux ls` and it said that "no server running"

probably cos you exec'd in as user root not user 'nobody', im assuming you have enabled irssi right?.

Share this post


Link to post
1 hour ago, binhex said:

probably cos you exec'd in as user root not user 'nobody', im assuming you have enabled irssi right?.

Ah yeah, that seems to be the problem. 

In order to access the container I do

 

docker exec -it binhex-rtorrentvpn /bin/bash

 

That logs me in as root.

 

How is the normal procedure to access it as nobody?

 

just

 

docker exec -it --user nobody binhex-rtorrentvpn /bin/bash?

 

Edited by Jeffarese

Share this post


Link to post
1 hour ago, Jeffarese said:

just

 

docker exec -it --user nobody binhex-rtorrentvpn /bin/bash?

 

yep thats it

Share this post


Link to post

Hi, long time user here:

My container is getting stuck here and isn't coming back up. I've waited about 10 minutes. Any idea?

 

2019-11-28 13:32:55,119 DEBG 'watchdog-script' stdout output:
[info] rTorrent not running

2019-11-28 13:32:55,124 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2019-11-28 13:32:55,124 DEBG 'watchdog-script' stdout output:
[info] rTorrent incoming port 49160 and VPN incoming port 48349 different, marking for reconfigure

2019-11-28 13:32:55,124 DEBG 'watchdog-script' stdout output:
[info] Removing any rTorrent session lock files left over from the previous run...

2019-11-28 13:32:55,126 DEBG 'watchdog-script' stdout output:
[info] Attempting to start rTorrent...

2019-11-28 13:32:55,127 DEBG 'watchdog-script' stdout output:
Script started, file is /home/nobody/typescript

2019-11-28 13:32:55,144 DEBG 'watchdog-script' stdout output:
Script done, file is /home/nobody/typescript

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.