4

I'm trying to understand a little better systemd by writing some services.

I have difficulties in understanding the differences between those 2 services for instance, well I'd like to be sure I understand them correctly would be more appropriate.

So for instance I got rtorrent service, defined as rt as a system service, that I can enable for user X,Y,Z, with sudo systemctl enable rt@userX.service

➜  ~  cat /etc/systemd/system/rt@.service
[Unit]
Description=rTorrent
Requires=network.target local-fs.target

[Service]
Type=forking
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
WorkingDirectory=/home/%I/
Restart=on-failure

[Install]
WantedBy=multi-user.target

and I got dropbox defined that way :

➜  ~  cat /etc/systemd/user/dropbox@.service
[Service]
ExecStart=/bin/sh %h/.dropbox-dist/dropboxd
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

If I understand well, the dropbox service can be started / stopped / enabled / disabled at a user level, for many users, even if that user isn't an admin. Does it mean I can as userX enable it for userY ? As for the rt service, only an admin can enable / start / stop it ... Is that the only difference between a system service and a user one ?

10

You're a bit muddled, yes. ☺ You have:

  • A set of system services that are managed by the system-wide instance of systemd; which are each an instatiation of a template service unit in the file /etc/systemd/system/rt@.service.
  • A set of user services that are managed by the per-user instances of systemd; which are each an instantiation of a template service unit in the file /etc/systemd/user/dropbox@.service.

You now need to understand this:

  • There is one system-wide instance of systemd. It always runs. It's process #1. Only an administrator has the authority to control system services.
  • There are multiple per-user instances of systemd. They are started/stopped on demand as users logon/logoff. They are not process #1. There is a maximum of one per user, however many times the user is logged on. Only that user (or an administrator) has the authority to control xyr own services.

A template service unit is a way of making multiple ad-hoc service units on the fly, that differ in the template parameter. The actual instantiated service units are named as a combination of the template name and the parameter.

Combined, this all means:

  • In your rt@.service the parameter is a user name, used to specify the user that the service runs as and the working directory that it runs in. So you can instantiate services such as rt@euri10.service and rt@david.service. These are system services, managed by the system-wide instance of systemd, and it takes an administrator to start and stop them. It just so happens that there's one per user.
  • In your dropbox@.service the parameter is ignored. You can instantiate services such as dropbox@wibble.service and dropbox@phooey.service. These are user services, managed by the per-user instances of systemd. Each user has xyr own separate set of template instantiations which that user can start and stop.

You possibly didn't want your dropbox service unit to be a template. Or you're now figuring out what that Environment=DISPLAY=%i setting was all about. ☺

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.