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 units 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.ddir 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.requiresAlias=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 .servicees. 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 andsystemdshould 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 tun1instance)