Systemd units basics
unit
- resource that system operates.
Systemd operates unit
files which can be multiple types .service
, .socket
, .device
etc. To start process we need only .service
file.
Unit files mostly stored in /etc/systemd/system
. There may be other directories with unit
s but this one has maximum priority.
For example system units are in /lib/systemd/system
. To override system unit, copy file from /lib/systemd/system
to /etc/systemd/system
and edit.
To override only specific directives, for unit named unit_name.service
create unit_name.service.d
directory in the /etc/systemd/system
and place .conf
file there with overridden or extended attributes.
Runtime units placed in /run/systemd/system
, this directory can be used to change units for session but changes will be lost after reboot.
Sections
- section names are case-sensetive, e.g.
[Unit]
custom user sections start with X-
- In case of overriding files inside of
unit.type.d
dir you can eliminate default value by assigning nothing:
Directive1=
values
For booleans you can use:
- true
1
,yes
,on
,true
- false
0
,no
,off
,false
Directives in [Unit]
section
Requires=
units on which this unit depends. They started in parallel with the current unit by default. If start of them impossible (not found or failed) current unit will also failWants=
likeRequires=
but less strict - will simply ignore failed units.BindsTo=
likeRequires=
but causes current unit stop if binded unit was terminatedBefore=
units which will wait for thisAfter=
units which should be started before thisConflicts=
units that can't run when this runCondition...=
conditions on which unit will be run, if not met it will be skippedAssert...=
as a condition but will cause failure instead of skipping
Directives in [Install]
section
[Install]
section used to define behavior when service enabled or disabled.
WantedBy=
- similar to Wants=
in [Unit]
section but related to called instead of caller: If current unit
has WantedBy=multi-user.target
, the directory multi-user.target.wants
will be created in /etc/systemd/system
(if not already available) and symlink to current unit
will be created in that dir when unit is enabled.
- This way it works.
RequiredBy=
similar to previous but will cause a fail if conditions not met. CreaAlias=te directory which ends with.requires
Alias=
allows the unit to be enabled under another name as wellAlso=
Supporting units that should always be available when this unit is activeDefaultInstance=
For template units (covered later) which can produce unit instances with unpredictable names, this can be used as a fallback value for the name if an appropriate name is not provided.
Directives in [Service]
section
Section available only for .service
es. Should provide Type=
which tells systemd
how to:
1. Call service process
2. Find out its state
Types:
simple
(default ifType=
not set butExecStart=
is set)forking
- tels that main process can fork child and exit immediately.PIDFile=
is used to set the path of the file with PID number of the main child that should be monitored.oneshot
- process will short lived andsystemd
should wait. Default when bothType=
andExecStart=
not set. To leave service in active state set even after process finished useRemainAfterExit=
- also there are other types.
starting process in service
ExecStart=
full path and args to command. To ignore non-zero exit codes use-
ad first character in commandExecStartPre=
same as previous but will be run before commandExecStartPost=
will be run after main process startedExecReload=
command that should used for reload if neededExecStop=
custom stop command. If not set process will be killedExecStopPost=
command to run after stop. Values:always
,on-success
,on-failure
,on-abnormal
,on-abort
, oron-watchdog
.Restart=
circumstances under which systemd will attempt to restartRestartSec=
specifies wait timeout before restart using previous settingTimeoutSec=
- how many systemd will wait for starting/stopping. If was not started will be marking failed, if not stopped will be forcefully killed. Separate timeout can be set as well:TimeoutStartSec=
andTimeoutStopSec=
Template units
Example of such unit: [email protected]
Instantiation of unit: [email protected]
An instance file is usually created as a symbolic link to the template file, with the link name including the instance identifier.
In the template it's possible to use variables:
%i
- instance name, e.g.instance1
%I
- same as above but with reversed escaping
Also
systemctl show unitFile
- shows info about unit filesystemctl start service.service
- start servicesystemctl enable service.service
- enable service (boot on start-up)systemctl start [email protected]
- enable service instance (e.g. hereopenvpn tun1
instance)