Would it be possible to provide a daemon version of rtorrent that doesn't have a UI and just sits there waiting for XML RPC requests? At the moment, I need to mess around with screen - if i just do rtorrent & disown, XML RPCs hang for some reason.
It doesn't even need to background itself, since start-stop-daemon can handle this pretty easily. (Actually, if you did make it background itself by using fork(), you would also need to create a pidfile somewhere so start-stop-daemon can get at the new pid).
It would be really useful for scripting things with torrents. transmission-daemon is the only other client that comes close in this regard, but their RPC client doesn't output machine-parseable data, and for some reason it's not connecting properly for my setup (but rtorrent does). Also they don't support the http_cacert options which is pretty important for what I want to do (encrypted backup over bittorrent).
It is one of those things I've wanted to do for a long time, but never got around to.
However with the improved logging facilities, etc, I might consider doing it... Well, at some point in time at least.
consider using rtorrent with screen you can get rtorrent to act as if it were a daemon.
that is what I'm doing currently, but this is not a clean solution. to shutdown rtorrent cleanly you need to send it a INT signal, but there is no way to get start-stop-daemon (the standard daemon manager on debian-based systems) to make screen send signals to the underlying child process.
Up to this! Lately I've been using Transmission, but it is not the same thing...
I know in gentoo there is an init-script provided that works well under gentoo's OpenRC init framework. Don't know how generally applicable/portable the same concepts would be
I modified rtorrent so that if it does not run in a terminal ncurses is not initialized and rtorrent does not crash. this means it can run headless. this should solve the problem described. see my fork of rtorrent. I sent a pull request yesterday for another issue but do not see how to send another one for this.
found the problem. I needed to send pull request from different branch. new pull request for this issue sent.
Is there any reason this pull request was never accepted? What I'm doing now (with screen) just seems clunky.
I'm pretty keen on this enhancement also... I might fork and import it myself...