I’m using an odroid C2 and flashed the lateste Stretch image.
The first problem I had was that some dietpi functions where missing on /boot/dietpi/func, like dietpi-ramlog, dietpi-banner, and others.
I’ve copied them from github and it started working again.
I’ve then installed rtorrent, Jackett, Emby, Syncthing and UrBackup.
When I try to use rutorrent, it says rtorrent isn’t running, when I go and check rtorrent service status it gives me this log:
Mode: status rtorrent
[FAILED] DietPi-Services | ● rtorrent.service - rTorrent (DietPi)
Loaded: loaded (/etc/systemd/system/rtorrent.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2020-05-07 19:11:31 BST; 1min 10s ago
Process: 950 ExecStop=/usr/bin/screen -S rtorrent -X quit (code=exited, status=1/FAILURE)
Process: 929 ExecStart=/usr/bin/screen -fa -dmS rtorrent /usr/bin/rtorrent (code=exited, status=0/SUCCESS)
Main PID: 930 (code=exited, status=0/SUCCESS)
May 07 19:11:30 DietPi systemd: Starting rTorrent (DietPi)...
May 07 19:11:30 DietPi systemd: Started rTorrent (DietPi).
May 07 19:11:31 DietPi screen: No screen session found.
May 07 19:11:31 DietPi systemd: rtorrent.service: Control process exited, code=exited status=1
May 07 19:11:31 DietPi systemd: rtorrent.service: Unit entered failed state.
May 07 19:11:31 DietPi systemd: rtorrent.service: Failed with result 'exit-code'.
As you can see, apparently the problem is that no screen session is found.
Can you guys please help me?
Ps.: I’ve used DietPi on this Odroid for a long time, maybe 3 or 4 years, I’ve never had these issues.
many thanks for your report. I tried to replicate your issues and indeed it seems to be related to the new version v6.29.2. I spend quite some time to find our what happen, but did not found a real solution yet.
I noticed that Rtorrent is working if you install it on v6.28 and do the update to v6.29.2 afterwards. Means in general it’s working on v6.29.2. However if you do the update first to v6.29.2 and installing Rtorrent afterwards, the service is not starting due to missing screen.
I tried getting screen up and running but without success. So it depends on the sequence how it is installed. But this doesn’t help you, as you have installed a new image and this will be bumped to latest DietPi release as soon as you start.
As well you are on Debian Stretch. On Buster it would be easier as there we could run Rtorrent in daemon mode and screen would not be needed anymore.
I also spend time to check the versions between Stretch and Buster.
Stretch - 0.9.6-2 - 06 Nov 2015
Buster - 0.9.7-1 - 28 Jun 2018
looking to the release date, I did not expect that someone will add daemon mode to Stretch version.
So only way would be to get screen running or you can try the new Buster image. It still has testing flag but maybe you can give it a try.
I’ve installed Buster and it all worked, even the functions were there. I had to change dht mode in .rtorrent.rc and had to change network.open_port to yes, but it’s not working yet. ruTorrent complains that the port is closed, I’m looking into it now.
It didn’t work, tried port forwarding, DMZ, edit the .rtorrent like the video. Unfortunately it didn’t work. I’m using a tp-link eifi mesh router and it created a sub network with different ips. I don’t know if this is the problem, woll try connecting odroid directly to ISP modem/router.
Hey guys, many thanks for reporting and debugging the issue. Indeed there was a bug our side where we set max memory allocation without adding an “M” for MiB, so I guess the effective value is in KiB now which is of course much too low. Fix is up: https://github.com/MichaIng/DietPi/pull/3531
We’ll as well hack this inside v6.30 systems via MOTD, to prevent future users from running into this, until v6.31 release.
Now I am not sure how DHT is related. Probably because it simply requires additional allocated memory. Could you guys try to leave DHT enabled after fixing the max memory string by adding a “M”? Maintaining a “distributed hash table” for trackerless torrents by default makes rTorrent more compatible without the need for user action. Not sure how well “auto” handles it, but of course, if keeping it enabled causes still issues, we’ll revert to “auto”.