Systemd
Systemd operates and manages things called units. Units have configuration files called unit files
Units are a group of standardized representations of the system resources. The system's copy of unit files are generally kept in the /lib/systemd/system directory. When a software installs a unit files on the system, it is placed there by default.
The files stored in this place are what systemd operates on. If you wish to change or modify a functionality of a unit, do not change the files stored in this directory. Instead, make a copy and store it in /etc/systemd/system directory. The system will take the unit files in this directory in precedence over /lib/systemd/system
If you wish to just change one directive in the unit file (and not replace the entire unit file), you can create a folder with the unit file's name, but ending with a .d and make a file ending with .conf. i.e. to change one directive in dummy.service, create a folder called dummy.service.d and place a .conf file inside.
systemd process also uses /run/systemd/system for dynamic creation of unit files created at runtime. This directory can be used to change the system's unit behavior for the duration of the session. All changes made in this directory will be lost when the system is rebooted.
In summary, there are three directories that systemd uses (in order of system precedence):
/etc/systemd/system/run/systemd/system/lib/systemd/system
Types of units
The suffix of a unit file tells us what kind of service it provides. Below shows the collection of types of units
| Suffix | Function |
|---|---|
| .service | This describes how to manage a service or an application on the system. This includes starting and stopping the service, when it should restart and the dependencies |
| .socket | This describes a network or an IPC socket |
| .device | Units that end with this suffix needs management by udev or sysfs |
| .mount | This defines a mount point on the system. They are names after the mount point path. Entries in /etc/fstab have units created automatically |
| .automount | This defines units that mount automatically. They must have a matching .mount unit |
| .swap | This describes the swap space on the system |
| .target | This provides synchronization points for other units when booting up or changing states. They can also be used to change the state of the system |
| .path | This defines a path that can be used for path-based activation |
| .timer | This defines a timer that will be managed by systemd |
| .snapshot | This unit is created when the command systemctl snapshot is executed |
| .slice | These unit files are associated with Linux Control Group nodes, allowing resources to be restricted or assigned to any process associated with that slice |
| .scope | These units are created automatically by systemd from information received from bus interfaces |
Different unit types work hand in hand to perform some functionality
Sections and Directives in a unit file
Inside the unit file, it has different sections. Sections are declared by surrounding square brackets [...] i.e. [SECTION NAME] .
Under the sections, we have the directives that are in the form of key=value
[SECTION NAME]
Directive=value
Directive=value
I will not go through all the directives and sections here, as they can be referred to online
Creating Units from Template Unit Files
Units can be created via templates. The templates are identified with an @ sign after the base unit name and before the unit type [email protected] i.e. [email protected]
When an instance is created from this template, we get something like this [email protected]. This instance has a symbolic link to the template file