rtorrent running but can't connect to ruTorrent

Troubleshooting
#1

This is on a fresh installation. I can verify that rtorrent is running by checking htop but the ruTorrent webUI says that connection is not established. I checked the scgi port settings on both and they match. However, entering the command

rtorrent

or

/usr/bin/rtorrent

on the terminal seems to temporarily fix the connection issue but then now I have 2 rtorrent processes running and closing the terminal also terminates the process.

DietPi v6.22
#2

Chester007
Many thanks for your report.

Jep I verified the bug: https://github.com/MichaIng/DietPi/issues/2629

I hope we can fix this for v6.22 which is about to be released soon.

#3

Thank you for noticing this issue. I was just about to report that I was able to replicate this on a newly installed system and on a different microsd card. I’m also hoping that this issue gets resolved soon. I personally prefer rtorrent over other torrent clients.

#4

Hi,
I also would like rutorrent webif to be working again

#5

The fix is already in Beta. If you want to test it: https://github.com/MichaIng/DietPi/issues/2632

#6

Now rutorrent connects, but download speed is 0 (through Nordvpn vpn)
I understand I need to setup a socks5 proxy with authentication, can that be done with rtorrent ?

#7

rTorrent has no internal SOCKS5 support: https://github.com/rakshasa/rtorrent/issues/105

So you would need to setup setup the proxy externally and make rTorrent use it. However a proxy should not be required, it is just recommended to stabilize and further anonymize the connection.

Did you verify that you use a P2P ready NordVPN server?

It works without VPN active, doesn’t it?

#8

After some playing around with the new update, I’ve found that changing the hostname to something other than DietPi also causes the problem where rutorrent can’t connect to rtorrent

#9

Hmm will check. Actually ruTorrenr should simply scan/show the local loopback IP for rTorrent instances so the hostname should not matter. Perhaps rTorrent only listens/answers requests sent to or associated with the hostname at the time it is started. But I would call this a bug actually. Does restarting rTorrent solve it?

#10

I tried restarting it using

dietpi-services restart rtorrent

but didn’t work

#11

Will try to replicate. Which webserver do you use? Default Lighttpd?

#12

Yes, default. Tried on two separate freshly installed DietPi

#13

Test with Lighttpd: Fresh install works well, ruTorrent connects automatically.

ruTorrent config.php contains:
$scgi_port = 5000;
$scgi_host = “127.0.0.1”;
which matches the default rTorrent .rtorrent.rc:
scgi_port = 127.0.0.1:5000

Hostname should not play a role. However testing to change hostname via dietpi-config + reboot:
… found it:

root@VM-Stretch:~# sudo -u rtorrent rtorrent
rtorrent: Could not lock session directory: "/mnt/dietpi_userdata/downloads/.session/", held by "DietPi:+17696".
root@VM-Stretch:~# rm /mnt/dietpi_userdata/downloads/.session/rtorrent.lock
root@VM-Stretch:~# systemctl restart rtorrent
root@VM-Stretch:~# cat /mnt/dietpi_userdata/downloads/.session/rtorrent.lock
VM-Stretch:+1341
root@VM-Stretch:~# systemctl status rtorrent
● rtorrent.service - rTorrent (DietPi)
   Loaded: loaded (/etc/systemd/system/rtorrent.service; disabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-04-04 18:29:03 CEST; 2s ago
  Process: 1352 ExecStop=/usr/bin/screen -S rtorrent -X quit (code=exited, status=0/SUCCESS)
  Process: 1355 ExecStart=/usr/bin/screen -fa -dmS rtorrent /usr/bin/rtorrent (code=exited, status=0/SUCCESS)
 Main PID: 1356 (screen)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/rtorrent.service
           ├─1356 /usr/bin/SCREEN -fa -dmS rtorrent /usr/bin/rtorrent
           └─1357 /usr/bin/rtorrent

Apr 04 18:29:03 VM-Stretch systemd[1]: Starting rTorrent (DietPi)...
Apr 04 18:29:03 VM-Stretch systemd[1]: Started rTorrent (DietPi).

So the session lock is done based on hostname. When changing the hostname this lock needs to be removed to allow rTorrent creating a new lock with new hostname.

So again from above the solution is:

rm /mnt/dietpi_userdata/downloads/.session/rtorrent.lock
systemctl restart rtorrent

Chester007
Very good find! I added this to our docs to hopefully prevent other users running into this: https://dietpi.com/forum/t/dietpi-software-details-for-all-installation-options/22/70
Would be great of rTorrent could print a meaningful error messages when running into this. It does when running it from terminal directly, but I guess it is a bid complicated through the systemd unit and the screen session below. The systemd unit creates output to the journal by default (journalctl and systemctl status rtorrent) but since the process is running inside a screen session again (and the screen process does not forward internal output reasonable), those messages do not reach somewhere. This should be handled way better with the new rTorrent internal daemon mode that allows to run it as daemon outside of a screen/tmux session. But this is new with version 0.9.7 and Debian Stretch still ships 0.9.6: