Allow rtorrent to run as a daemon, slightly modified version of #111

[zp]

Implements a system.use_daemon variable that allows users to enable daemon mode via system.use_daemon.set = true in .rtorrent.rc

Credits to @sallyswiss for basically all of the code in #111.

[asavah]

Built latest master with this PR, works as intended.
Had to tinker a little with the systemd unit, I'll leave it here in case someone needs it:

[Unit]
Description=systemd integration for rtorrent - starts/stops rtorrent instances on startup/shutdown
Wants=network-online.target
After=network-online.target

[Service]
User=rtorrent
Group=rtorrent
Type=simple
KillMode=process
Environment="HOME=/media/nas/public"
ExecStart=/opt/builds/rtorrent/bin/rtorrent -n -o import=/etc/rtorrent.d/nas2.rc
WorkingDirectory=/media/nas/public

[Install]
WantedBy=multi-user.target

Change username and paths accordingly.
Of course /etc/rtorrent.d/nas2.rc contains system.use_daemon.set = true.

[soullivaneuh]

This great feature has now more than 1 year old.

When would you push a new stable version or rtorrent? :-)

Thanks.

[rakshasa]

When feature-bind is ready.

[0xcaff]

For anyone trying to run the development build, the setting is system.daemon now (ref).

[cantalupo555]

rtorrent: Failed to parse command line option: Error in option file: /root/.rtorrent.rc:4: Command "system.use_daemon.set" does not exist.

Daemon not yet available?

[0xcaff]

Read the comment above yours @cantalupo555

[opoei]

Hopefully this is helpful; system.daemon = true is accepted (No stderr / return 0), whereas the proper config is system.daemon.set = true

[Perlovka]

@asavah
Maybe, it's better to start daemon like this:

ExecStart=/opt/builds/rtorrent/bin/rtorrent -o system.daemon.set=true

So, you'll be able to start rtorrent as usual without changing system.daemon.set option in file.

[asavah]

@Perlovka it's better to not start it at all, since it looks like rtorrent is mostly abandoned, and bugs are not getting fixed. eg #443 and the whole lot in the tracker.
Been using deluged 2.x beta for more than a year and I'm happy with it, libtorrent_rasterbar https://github.com/arvidn/libtorrent is so much better and cleaner implementation than this pile (rtorrent + libtorrent) of abandonware.

[kannibalox]

@Perlovka it's better to not start it at all, since it looks like rtorrent is mostly abandoned

that might have been a good argument before the more recent release

Been using deluged 2.x beta for more than a year and I'm happy with it, libtorrent_rasterbar https://github.com/arvidn/libtorrent is so much better and cleaner implementation than this pile (rtorrent + libtorrent) of abandonware.

glad to hear it, you won't see me promoting rtorrent on libtorrent_rasterbar's issue tracker though

[Perlovka]

@asavah so why this better and cleaner implementation have more than 200 open bugs?

I'm using rtorrent for more than 7 years (at least). And the only time it needed my attention were changes for 0.9.7 release. I'm very happy with this result.

[asavah]

@Perlovka care to name a software project without bugs?
It's not about having bugs but about fixing them,
and the developer of libtorrent_rasterbar is actively maintaining his project and actually fxing bugs and improving the code. This does not happen here, the developer of this project seem to have lost interest in this or he simply doesn't have time for this, which is ok, I have no problem with this,
but I will not use something outdated which hasn't had the much needed attention from its author in years.
I think have tried every torrent client for linux and my choice is deluged.
The only thing I miss is ruTorrent which is a very nice and convenient gui for rtorrent.

I have an extensive torrent collection which I'm seeding on a gigabit link,
when my collection started to grow I've hit #443 ,
which is an absolute show stopper. You may have no problems with rtorrent because you just download something from time to time on a dsl line... I haven't had problems too and was quite happy until both my internet and my server got beefed up , and then the IO issue linked above showed up and it became worse with every torrent added. I have much bigger collection now (4TB of crap and growing) and deluged + libtorrent_rasterbar work very nicely with no crashes and without terrible IO overhead.

[kannibalox]

You may have no problems with rtorrent because you just download something from time to time on a dsl line...

I'm seeding 20k+ torrents on a gigabit line, and I don't denigrate people based on sheer assumptions.

I'm certainly not saying rtorrent is the best client for everyone in all circumstance, or that aren't some rough bugs out there. If Deluge works better for your case, more power to you. I just wanted to make sure there was a nod to @rakshasa's recent efforts in getting the 0.9.7 release out there, which contains a bunch of bug fixes, meaning that rtorrent isn't abandonware or anything. There's also projects like rtorrent-ps and rtorrent-ps-ch that are actively updated as well.

[dausruddin]

Anyone know the right way to use the daemon mode? I have tried systemd unit as @asavah wrote at the top, but rtorrent will ignore all recent torrents added after a process restart. I even tried using KillMode=SIGINT but the issue persist.

Edit: files torrent, libtorrent_resume and rtorrent of that particular torrent exists in my session folder. But somehow rtorrent ignore them

[pyroscope]

That is the beauty of this daemon mode, you struck yourself blind and are unable to diagnose anything. 👍

[theAkito]

That is the beauty of this daemon mode, you struck yourself blind and are unable to diagnose anything. 👍

That's why I run everything in foreground within tmux...

[wheelerlaw]

@pyroscope Perhaps a PR is in order then to integrate rtorrent with syslogd (or journald if running in an OS with systemd)

[wiltonsr]

Hello,

Thanks for rtorrent.

How can I open rtorrent with screen when its running in daemon mode?

[rakshasa]

You can't, there's not ncurses ui when it is in daemon mode.

[wiltonsr]

Thanks for reply @rakshasa,

Would be nice to add a daemon mode that is possible to open ncurses ui.

Maybe open a new feature request issue to be possible for others to give their opinion in the discussion would be the best choice.

[rakshasa]

I already have a design for that, using protobuf protocol to connect an ncurses ui to rtorrent.

[chros73]

Hmm, interesting. Although personally I don't really see the point, if someone needs to access to the GUI then why doesn't just start it in tmux then?

[rakshasa]

The point of protobuf is to use it to separate out xmlrpc, and a future implementation of websocket support, from the rtorrent process. This would allow you to write custom tools to interact with rtorrent that is not restricted by xmlrpc and doesn't require you to touch the complexity of the core client.

[wiltonsr]

Hi, @rakshasa.

While the protobuf approach is not yet implemented, what issues and implications may occur when running multiple instances of rtorrent using the same session folder?

I'm thinking of using a systemd service to run an instance of rtorrent, which will explicitly run in daemon mode.
rtorrent -o system.daemon.set=true

and using the setting session.use_lock.set = no like this when starting rtorrent in normal mode the download, session, watch, ... folders would all be shared between the two instances.

Is there a problem using rtorrent this way?

[rakshasa]

The torrent sessions still get saved to that directory so they'll cause conflict, better to have separate session directories and seed the torrents from the same data files.