Reading a tutorial on systemd...just dont understand this

sigint-ninja · 11-15-2015, 10:17 AM

Hi guys,

was reading a tutorial from archwiki on systemd...

Then read this:

"Note: Some unit names contain an @ sign (e.g. name@string.service): this means that they are instances of a template unit, whose actual file name does not contain the string part (e.g. name@.service). string is called the instance identifier, and is similar to an argument that is passed to the template unit when called with the systemctl command: in the unit file it will substitute the %i specifier.
To be more accurate, before trying to instantiate the name@.suffix template unit, systemd will actually look for a unit with the exact name@string.suffix file name, although by convention such a "clash" happens rarely, i.e. most unit files containing an @ sign are meant to be templates. Also, if a template unit is called without an instance identifier, it will just fail, since the %i specifier cannot be substituted.

I just dont understand the practical application of this...

can anybody help me clear this up...?

TobiSGD · 11-15-2015, 10:29 AM

You can use this to start a specific service for different users or with different options. For example, this can be used to start a tmux session at boot for different users, using this template:

Code:

[Unit]
Description=Start tmux in detached session

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

[Install]
WantedBy=multi-user.target

When this template is saved as /etc/systemd/system/tmux@.service you can use

Code:

systemctl enable tmux@tobi.service

to start a tmux session for my user on boot. This is of course not limited to different users, it can be used to start different systemd-nspawn containers at boot, basically anything you can think of that benefits from specifying an option to a template.

smallpond · 11-15-2015, 12:11 PM

Systemd could have used an existing method, such as an argument:

Code:

systemctl enable tmux.service tobi

or a parameterized call:

Code:

systemctl enable tmux.service %i=tobi

or an environment variable:

Code:

USER=tobi systemctl enable tmux.service

but it is more in keeping with systemd's style to invent a new and unfamiliar mechanism which also creates an unexpected dependency between filenames and arguments. Also, unlike the more familiar methods, systemd's instance name cannot be extended to multiple arguments.

TobiSGD · 11-15-2015, 01:30 PM

Quote:

Originally Posted by smallpond

Systemd could have used an existing method, such as an argument:

Code:

systemctl enable tmux.service tobi

or a parameterized call:

Code:

systemctl enable tmux.service %i=tobi

or an environment variable:

Code:

USER=tobi systemctl enable tmux.service

but it is more in keeping with systemd's style to invent a new and unfamiliar mechanism which also creates an unexpected dependency between filenames and arguments. Also, unlike the more familiar methods, systemd's instance name cannot be extended to multiple arguments.

Do you have anything meaningful to contribute or are you just here for ranting?

Doug G · 11-15-2015, 09:49 PM

Quote:

Do you have anything meaningful to contribute or are you just here for ranting?

My guess is just ranting.

Thank you for the explanation, I didn't have any understanding of systemd templates until I read your post.