b.stefanuk.ca

Appearance

Using Systemd Service Files ​

Systemd service files allow one to manage system daemons on Linux. Service files bear the .service extension, and the primary means of interacting with them is through the systemctl command. T

he example below provides a sane and practical starting point for a service that will restart if terminated. This is usually enough to meet most goal, but if you need advanced functionality, reference the service file options.

/lib/systemd/system/simple.service

toml
[Unit]
Description=Custom service file to do with what you please
Wants=syslog.target
After=syslog.target network.target

[Service]
Type=simple
User=braden
ExecStart=/usr/local/bin/your_executable
ExecReload=/usr/local/bin/your_executable
EnvironmentFile=/etc/relevant_environment_variables
Restart=on-failure
RestartSec=10
TimeoutSec=10

[Install]
WantedBy=multi-user.target
[Unit]
Description=Custom service file to do with what you please
Wants=syslog.target
After=syslog.target network.target

[Service]
Type=simple
User=braden
ExecStart=/usr/local/bin/your_executable
ExecReload=/usr/local/bin/your_executable
EnvironmentFile=/etc/relevant_environment_variables
Restart=on-failure
RestartSec=10
TimeoutSec=10

[Install]
WantedBy=multi-user.target
Info

Notice the field ExecStart; this is the command that is issued to start the service.

Where to put systemd unit files depends on whether they're system or user units.

To check the where systemd will search for system unit files use

sh
systemd-analyze --system unit-paths
systemd-analyze --system unit-paths

To check where user unit files will be searched use

sh
systemd-analyze --user unit-paths
systemd-analyze --user unit-paths

Also see Where do I put my systemd unit file? and the systemd.unit man pages.

To extract systemd install locations for use in scripts you can use pkg-config (See [[Using CMake with pkg-config]]). Since pkg-config stores metainformation about installed packages, system-specific install locations can be extracted from Systemd's pkg-config file (mine's located at /usr/share/pkgconfig/systemd.pc). If you less systemd.pc, you can see all of the variables that are defined for that package, e.g.,

sh
...
prefix=/usr
rootprefix=
sysconfdir=/etc
systemdutildir=${rootprefix}/lib/systemd
systemdsystemunitdir=${rootprefix}/lib/systemd/system
systemdsystempresetdir=${rootprefix}/lib/systemd/system-preset
systemduserunitdir=${prefix}/lib/systemd/user
systemduserpresetdir=${prefix}/lib/systemd/user-preset
systemdsystemconfdir=${sysconfdir}/systemd/system
...
...
prefix=/usr
rootprefix=
sysconfdir=/etc
systemdutildir=${rootprefix}/lib/systemd
systemdsystemunitdir=${rootprefix}/lib/systemd/system
systemdsystempresetdir=${rootprefix}/lib/systemd/system-preset
systemduserunitdir=${prefix}/lib/systemd/user
systemduserpresetdir=${prefix}/lib/systemd/user-preset
systemdsystemconfdir=${sysconfdir}/systemd/system
...

These variables can be queried with the pkg-config executable.

sh
pkg-config systemd --variable=systemdsystemunitdir
pkg-config systemd --variable=systemdsystemunitdir

Tips and Tricks ​

A Note on Syntax ​

When using fields such as Wants, Requires, or After, etc. note that "This option may be specified more than once or multiple space-separated units may be specified in one option".

ini
# Both of the following are correct
# Option 1
Wants=unit1.service
Wants=unit2.service
# Option 2
Wants=unit1.service unit2.service
# Both of the following are correct
# Option 1
Wants=unit1.service
Wants=unit2.service
# Option 2
Wants=unit1.service unit2.service

Use Wants before Requires ​

As per the man-pages:

"Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services."

It's Okay to Use Both Wants and After ​

Wants (and Requires) is used to declare a dependency, and triggers simultaneous start-up of the services. If it is desirable to have one boot sequentialls, then use After (or Before) to establish sequential start-up.

ADDITIONAL RESOURCES