systemd, tmux and rTorrent

kazuldur · 2012-08-15 16:02:17

Hello.
I finally found some time to migrate to systemd. Almost everything went smooth, there is only one thing I can't figure out. I want to run rtorrent in dedicated tmux session as user (not root). With initscripts basically it was enough to run

su - kaz -c 'tmux new-session -d -s rtorrent rtorrent' &> /dev/null

in /etc/rc.d/rtorrent and add rtorrent to DAEMONS array.
In systemd I've tried to write my own .service file and run systemctl enable rtorrent.service. That's what I have in /etc/systemd/system/rtorrent.service:

[Unit]
Description=rTorrent for kaz

[Service]
ExecStart=/usr/bin/tmux new-session -d -s rtorrent rtorrent
Type=oneshot
User=kaz

[Install]
WantedBy=multi-user.target

And it even works when I run systemctl start rtorrent.service (I have new session with rtorrent in tmux), but it doesn't after reboot. The output of systemctl status rtorrent.service is the same right after reboot and after manually starting rtorrent.service (except the time and PID of course):

[kaz@Dmitrij system]$ systemctl status rtorrent.service 
rtorrent.service - rTorrent for kaz
          Loaded: loaded (/etc/systemd/system/rtorrent.service; enabled)
          Active: inactive (dead) since Wed, 15 Aug 2012 17:32:38 +0200; 16min ago
         Process: 408 ExecStart=/usr/bin/tmux new-session -d -s rtorrent rtorrent (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/rtorrent.service

[kaz@Dmitrij system]$

Does tmux depend on anything to run? Some variables maybe?
And it would be great if I could get systemd to restart rtorrent when it exits, but I'm not sure how to do that...

Last edited by kazuldur (2012-08-15 16:06:49)

Steven Monday · 2012-08-17 01:24:44

Check the journal after a reboot for error messages related to your rtorrent.service, like this:

journalctl -b _SYSTEMD_UNIT=rtorrent.service

or maybe this:

journalctl -b | grep rtorrent

Just a hunch (I could be wrong), but it's possible that during boot-up systemd tries to start rtorrent.service before the network is up, causing rtorrent to bail out. Try adding

After=network.target

to the [Unit] section of your rtorrent.service file.

Also, it may be prudent to specify the full pathname for rtorrent in ExecStart=, to eliminate the possibility of a PATH problem.

kazuldur · 2012-08-17 10:24:29

Thanks for your post.

Steven Monday wrote:

Check the journal after a reboot for error messages related to your rtorrent.service, like this:
journalctl -b _SYSTEMD_UNIT=rtorrent.service
or maybe this:
journalctl -b | grep rtorrent

There are no messages related to rtorrent at all.

Steven Monday wrote:

Just a hunch (I could be wrong), but it's possible that during boot-up systemd tries to start rtorrent.service before the network is up, causing rtorrent to bail out. Try adding
After=network.target
to the [Unit] section of your rtorrent.service file.
Also, it may be prudent to specify the full pathname for rtorrent in ExecStart=, to eliminate the possibility of a PATH problem.

I've checked and rtorrent doesn't exit when network is unreachable. However I've added After=network.target line and the full pathname, but it still just doesn't run.

Stebalien · 2012-08-17 15:48:00

This may have nothing to do with your problem but, IIRC, tmux needs access to a console (/tty/pty/etc.) to run (even if it doesn't end up using it). You could try giving it access to a tty (man systemd.exec).

kazuldur · 2012-08-17 17:12:59

It finally works. All I had to do was set Type=forking.

[Unit]
Description=rTorrent for kaz

[Service]
ExecStart=/usr/bin/tmux new-session -d -s rtorrent rtorrent
Type=forking
User=kaz

[Install]
WantedBy=multi-user.target

Now I have to do another service to start tmux server so I could start and stop rtorrent.service as many times as I want without killing other sessions

anachron8 · 2012-10-09 08:48:44

kazuldur wrote:

Now I have to do another service to start tmux server so I could start and stop rtorrent.service as many times as I want without killing other sessions

So this is a little late and I am sure you have figured it out by now, but in case anyone else comes here with the same question: Here's how to stop just rtorrent:

[Service]
...
ExecStop=/usr/bin/tmux kill-session -t rtorrent
...

WonderWoofy · 2012-10-12 21:27:40

Hey, thanks for this. I am just learning the ways of tmux. I know everyone loves screen, but in my brief adventures with both, I think I like tmux better.

I just made one change, I made the service file rtorrent-tmux@.service and then set User=%I , so it ended up like this

[Unit]
Description=Start rTorrent in detached tmux session

[Service]
Type=forking
ExecStart=/usr/bin/tmux new-session -d -s rtorrent rtorrent
ExecStop=/usr/bin/tmux kill-session -t rtorrent
User=%I

[Install]
WantedBy=multi-user.target

desijuan89 · 2013-03-29 20:43:56

I think it is better to put:

ExecStop=/usr/bin/tmux send-keys C-q -t rt

So that it waits for rtorrent to stop, instead of killing the session.

What do you think?

Last edited by desijuan89 (2013-03-30 02:01:27)

desijuan89 · 2013-03-30 01:22:18

The only drawback with this is that you have to be sure that there is no other window than the "rtorrent" window in the "rt" session.

I tried something like this, but it didn't worked:

ExecStart=/usr/bin/tmux new-session -n rtorr -s rt -d rtorrent
ExecStop=/usr/bin/tmux kill-window -a -t rt:rtorr \; send-keys C-q -t rt:rtorr

I want to kill all the other windows than "rtorr" and then send C-q to this window.

Help??

Last edited by desijuan89 (2013-03-30 02:21:37)

cngn · 2013-04-05 15:43:29

Proper:

/etc/systemd/system/rt@.service

[Unit]
Description=rTorrent
Requires=network.target local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
KillMode=none
User=%I
ExecStart=/usr/bin/tmux new-session -s rt -n rtorrent -d rtorrent 
ExecStop=/usr/bin/tmux send-keys -t rt:rtorrent C-q

[Install]
WantedBy=multi-user.target

desijuan89 · 2013-04-11 06:29:53

desijuan89 wrote:

The only drawback with this is that you have to be sure that there is no other window than the "rtorrent" window in the "rt" session.
I tried something like this, but it didn't worked:
ExecStart=/usr/bin/tmux new-session -n rtorr -s rt -d rtorrent
ExecStop=/usr/bin/tmux kill-window -a -t rt:rtorr \; send-keys C-q -t rt:rtorr
I want to kill all the other windows than "rtorr" and then send C-q to this window.
Help??

I found the solution , here it is:

ExecStop=/usr/bin/tmux kill-window -a -t rt:rtorr ; /usr/bin/tmux send-keys -t rt:rtorr C-q

Last edited by desijuan89 (2013-04-11 06:37:09)

sunite · 2013-05-04 14:57:00

Hi guys,

I have been trying to create a systemd service to start up a tmux session with the first window being rtorrent and the second window being irssi (with autodl), however my service is not working.

I decided to remove all the extra stuff just to see if I was doing something wrong, my current service file looks like this:

[Unit]
Description=rTorrent and AutoDL-Irssi
Requires=network.target local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
KillMode=none
User=%I
ExecStart=/usr/bin/tmux new-session -d -s rt -n rtorrent rtorrent
#ExecStartPost=/usr/bin/tmux new-window -d -t rt -n autodl -d irssi
ExecStop=/usr/bin/tmux send-keys -t rt:rtorrent C-q
#ExecStop=/usr/bin/tmux send-keys -t rt:autodl '/quit' Enter
#WorkingDirectory=/home/%I/

[Install]
WantedBy=multi-user.target

This executes without any errors: 'systemctl start rt@USER.service' where user is a USER on the system. I get the following from 'systemctl status rt@USER.service':

root@server1 ~
$ systemctl status rt@USER.service
rt@USER.service - rTorrent and AutoDL-Irssi
   Loaded: loaded (/etc/systemd/system/rt@.service; disabled)
   Active: active (exited) since Sat 2013-05-04 15:36:02 BST; 17min ago
 Main PID: 12655 (code=exited, status=0/SUCCESS)
   CGroup: name=systemd:/system/rt@.service/USER

May 04 15:36:02 server1.master-slave.info systemd[1]: Starting rTorrent and AutoDL-Irssi...
May 04 15:36:02 server1.master-slave.info systemd[1]: Started rTorrent and AutoDL-Irssi.

As you can see, tmux seems to have started but then exits right away. I can confirm this by using 'ps', no tmux session or any of the windows are to be found in the process table, even under that PID (12655).

What do you guys think?

EDIT 1:

Ok, it seems it's not so much a problem with systemd or the service file but tmux. I just tried to 'tmux new-session -d -s bob -n rtorrent rtorrent' and it just exited.

EDIT 2:

I am using this release of rtorrent: AUR rtorrent-pyro-git

Last edited by sunite (2013-05-04 15:08:49)

WonderWoofy · 2013-05-04 15:18:46

Di you have a tmux config? If so can you try it without any config, just plain vanilla tmux?

Also, why are you using the "send-keys" tmux command for ExecStop=? Why not just use "/usr/bin/tmux kill-session -t <session-name>"?

sunite · 2013-05-04 15:24:55

WonderWoofy wrote:

Di you have a tmux config? If so can you try it without any config, just plain vanilla tmux?

No, there are no tmux configs. I just switched from screen to tmux last month.

WonderWoofy wrote:

Also, why are you using the "send-keys" tmux command for ExecStop=? Why not just use "/usr/bin/tmux kill-session -t <session-name>"?

No particular reason I guess, I just want to cleanly exit rtorrent.

WonderWoofy · 2013-05-04 19:57:06

Oh, it should not be oneshot. Oneshot is intended to exit after the command. You are trying to run a real service here, where it is continuous and monitored by systemd. I think you should just omit the Type= line, or possibly use simple. I don't think this would be considered forking, but I could totally be wrong.

In any case, oneshot is actually doing its job here as intended... just not what you intended.

Edit: Also, I am not sure that it will matter, but it is probably a good idea to use the full path to rtorrent. It is just good practice when writing systemd units.

Last edited by WonderWoofy (2013-05-04 19:57:53)

sunite · 2013-05-05 12:26:29

WonderWoofy wrote:

Oh, it should not be oneshot. Oneshot is intended to exit after the command. You are trying to run a real service here, where it is continuous and monitored by systemd. I think you should just omit the Type= line, or possibly use simple. I don't think this would be considered forking, but I could totally be wrong.
In any case, oneshot is actually doing its job here as intended... just not what you intended.

Edit: Also, I am not sure that it will matter, but it is probably a good idea to use the full path to rtorrent. It is just good practice when writing systemd units.

Thanks for that, however as I suspected, it wasn't systmed that was causing the problem. Because I am using a modified version of rtorrent (with color support), I had to set the $TERM to set "screen-256color". I did this by creating the conf file /etc/tmux.conf (so that it is system wide), and added to it:

set -g default-terminal "screen-256color"

After that rtorrent now starts within a tmux session.

I did some playing around with the service file to get everything working right, and as it turns out it works best with

Type=forking

Here is now my complete and working rt@.service file:

[Unit]
Description=rTorrent and AutoDL-Irssi
Requires=network.target local-fs.target

[Service]
Type=forking
KillMode=none
User=%I
ExecStart=/usr/bin/tmux new-session -d -P -s rt -n rtorrent /usr/bin/rtorrent
ExecStartPost=/usr/bin/tmux new-window -a -d -P -t rt -n autodl /usr/bin/irssi
ExecStop=/usr/bin/tmux send-keys -t rt:autodl '/quit' Enter
ExecStop=/usr/bin/tmux send-keys -t rt:rtorrent C-q

[Install]
WantedBy=multi-user.target

WonderWoofy · 2013-05-05 12:31:22

Don't forget to mark the thread as solved.

cngn · 2013-05-05 17:22:04

sunite wrote:

Here is now my complete and working rt@.service file:

[Unit]
Description=rTorrent and AutoDL-Irssi
Requires=network.target local-fs.target

[Service]
Type=forking
KillMode=none
User=%I
ExecStart=/usr/bin/tmux new-session -d -P -s rt -n rtorrent /usr/bin/rtorrent
ExecStartPost=/usr/bin/tmux new-window -a -d -P -t rt -n autodl /usr/bin/irssi
ExecStop=/usr/bin/tmux send-keys -t rt:autodl '/quit' Enter
ExecStop=/usr/bin/tmux send-keys -t rt:rtorrent C-q

[Install]
WantedBy=multi-user.target

You need Type=oneshot. Type=forking will prevent you from using multiple tmux sessions. Try this: first run 'tmux new -s test -d'. Then start your session 'systemctl start rt@user'. Then run 'tmux ls'.

space@arch ~ :( $ cat /etc/systemd/system/tmux@.service
[Unit]
Description=Start tmux in detached session

[Service]
Type=forking
KillMode=none
User=%I
ExecStart=/usr/bin/tmux new-session -s %u -d
ExecStop=/usr/bin/tmux kill-session -t %u

[Install]
WantedBy=multi-user.target
space@arch ~ $ tmux ls
failed to connect to server
space@arch ~ :( $ tmux new -s test -d && tmux ls
test: 1 windows (created Sun May  5 19:36:33 2013) [144x39]
space@arch ~ $ sudo systemctl start tmux@space
space@arch ~ $ tmux ls
test: 1 windows (created Sun May  5 19:36:33 2013) [144x39]
space@arch ~ $

Last edited by cngn (2013-05-05 17:38:37)

sunite · 2013-05-05 18:59:50

cngn wrote:

You need Type=oneshot. Type=forking will prevent you from using multiple tmux sessions. Try this: first run 'tmux new -s test -d'. Then start your session 'systemctl start rt@user'. Then run 'tmux ls'.

space@arch ~ :( $ cat /etc/systemd/system/tmux@.service
[Unit]
Description=Start tmux in detached session

[Service]
Type=forking
KillMode=none
User=%I
ExecStart=/usr/bin/tmux new-session -s %u -d
ExecStop=/usr/bin/tmux kill-session -t %u

[Install]
WantedBy=multi-user.target
space@arch ~ $ tmux ls
failed to connect to server
space@arch ~ :( $ tmux new -s test -d && tmux ls
test: 1 windows (created Sun May  5 19:36:33 2013) [144x39]
space@arch ~ $ sudo systemctl start tmux@space
space@arch ~ $ tmux ls
test: 1 windows (created Sun May  5 19:36:33 2013) [144x39]
space@arch ~ $

Thanks for that, I did not notice that. However now I get something weird, if I already had a tmux session running, this simply merges the new windows into it (at least that it what is looks like from htop)

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
    1 root       20   0 32772  3560  1944 S  0.0  0.0  0:02.77 /sbin/init
29363 hans       20   0 18228  1820  1268 S  0.0  0.0  0:00.38 ├─ tmux new-session -d -s test
30787 hans       20   0 16252  2732  1684 S  0.0  0.0  0:00.01 │  ├─ -bash
30512 hans       20   0  189M 28044  6364 S  0.0  0.2  0:00.35 │  ├─ /usr/bin/irssi
30520 hans       20   0  189M 28044  6364 S  0.0  0.2  0:00.00 │  │  └─ /usr/bin/irssi
30508 hans       20   0  434M  160M  5220 S  0.0  1.3  0:01.76 │  └─ /usr/bin/rtorrent
30521 hans       20   0  434M  160M  5220 S  0.0  1.3  0:00.00 │     ├─ /usr/bin/rtorrent
30511 hans       20   0  434M  160M  5220 S  0.0  1.3  0:00.00 │     └─ /usr/bin/rtorrent

but if I go to the user and do 'tmux list-sessions', its shows 2 sessions:

$ tmux list-sessions
rt: 2 windows (created Sun May  5 19:50:46 2013) [80x23]
test: 1 windows (created Sun May  5 19:19:20 2013) [80x23]

I'll read up a bit more on tmux (i think this might be a tmux related, and not something to do with systemd).

cngn · 2013-05-06 08:12:15

sunite wrote:

if I already had a tmux session running, this simply merges the new windows into it (at least that it what is looks like from htop)

This is tmux's standard behavior. Initiating the commands by hand in a terminal will yield same results. Terminating this session, 'test', while leaving remaining sessions running will not erase the session's name from the command shown by htop. It's because the first line points to a running server, not necessarily to the session itself. Htop just show the command that caused the server to start even if its original session was terminated.

sunite · 2013-05-06 09:36:36

cngn wrote:

sunite wrote:
if I already had a tmux session running, this simply merges the new windows into it (at least that it what is looks like from htop)
This is tmux's standard behavior. Initiating the commands by hand in a terminal will yield same results. Terminating this session, 'test', while leaving remaining sessions running will not erase the session's name from the command shown by htop. It's because the first line points to a running server, not necessarily to the session itself. Htop just show the command that caused the server to start even if its original session was terminated.

Brilliant, thanks

lesto · 2013-05-07 19:54:18

this should be in the tTorrent's page in wiki!

WonderWoofy · 2013-05-08 01:04:06

lesto wrote:

this should be in the tTorrent's page in wiki!

Put it there.

Arch Linux

#1 2012-08-15 16:02:17

systemd, tmux and rTorrent

#2 2012-08-17 01:24:44

Re: systemd, tmux and rTorrent

#3 2012-08-17 10:24:29

Re: systemd, tmux and rTorrent

#4 2012-08-17 15:48:00

Re: systemd, tmux and rTorrent

#5 2012-08-17 17:12:59

Re: systemd, tmux and rTorrent

#6 2012-10-09 08:48:44

Re: systemd, tmux and rTorrent

#7 2012-10-12 21:27:40

Re: systemd, tmux and rTorrent

#8 2013-03-29 20:43:56

Re: systemd, tmux and rTorrent

#9 2013-03-30 01:22:18

Re: systemd, tmux and rTorrent

#10 2013-04-05 15:43:29

Re: systemd, tmux and rTorrent

#11 2013-04-11 06:29:53

Re: systemd, tmux and rTorrent

#12 2013-05-04 14:57:00

Re: systemd, tmux and rTorrent

#13 2013-05-04 15:18:46

Re: systemd, tmux and rTorrent

#14 2013-05-04 15:24:55

Re: systemd, tmux and rTorrent

#15 2013-05-04 19:57:06

Re: systemd, tmux and rTorrent

#16 2013-05-05 12:26:29

Re: systemd, tmux and rTorrent

#17 2013-05-05 12:31:22

Re: systemd, tmux and rTorrent

#18 2013-05-05 17:22:04

Re: systemd, tmux and rTorrent

#19 2013-05-05 18:59:50

Re: systemd, tmux and rTorrent

#20 2013-05-06 08:12:15

Re: systemd, tmux and rTorrent

#21 2013-05-06 09:36:36

Re: systemd, tmux and rTorrent

#22 2013-05-07 19:54:18

Re: systemd, tmux and rTorrent

#23 2013-05-08 01:04:06

Re: systemd, tmux and rTorrent

Board footer