This tutorial explains Systemd unit configuration files in detail. Learn how systemd unit configuration files are formatted along with the types and locations of systemd unit configuration files.
Systemd uses units to manage system services and processes. Systemd units use configuration files to control their related operations. There are three types of unit configuration files; default unit configuration files, system specific unit configuration files, and run-time unit configuration files.
This tutorial is the third part of the article "Functionalities and usages of the systemd in Linux explained with practical examples". Other parts of this article are the following.
The following table lists the location of all three types of unit configuration files.
| Type of unit configuration files | Location |
| Default unit configuration files | /usr/lib/systemd/system |
| Run-time unit configuration files | /run/systemd/system |
| System specific unit configuration files | /etc/systemd/system |
Default unit configuration files contain the default configuration of units. When we install a new package, during the installation, its unit configuration file is also installed/generated in the /usr/lib/systemd/system directory.
Run-time unit configuration files are automatically generated and deleted when a unit starts and stops respectively.
System specific unit configuration files contain the customized configuration of units. Through these configuration files, a user can override the default behavior of units.
When we make any change in the state of a service or process such as; start, stop, enable, and disable, the systemd reads and executes its unit configuration file. Unit configuration files are checked in the following sequence.
System specific unit configuration files => Run-time unit configuration files => Default unit configuration files.
Run-time unit configuration files take precedence over the default unit configuration files, and the system specific unit configuration files take priority over the run-time unit configuration files.
In easy language, in the above sequence, the next unit configuration file is used only if the current unit configuration is not available. For example, if all three configuration files of a unit are available, then only the system specific unit configuration file is used.
This pre-defined order allows users to customize services and processes as per his requirement.
If you want to change/modify/update a unit configuration file, don’t change the default unit configuration file (located in the /usr/lib/systemd/system directory). When you update software packages or Linux to new version, configuration files stored in this directory are also updated. During the update, your changes may be overwritten. Instead of making any change in the default unit configuration file, copy the default unit configuration file in the /etc/systemd/system directory and change/modify/update it as per your requirement.
Format of systemd unit configuration files
A systemd unit configuration file contains all required information to control that unit such as; the path of the file which starts the unit, the name of services/units which need to start before and after the unit, documentation location, dependency information, conflict information, etc.
Even a unit configuration file contains a lot of information, understanding it is relatively easy. Information in unit configuration file usually categorized in three sections; [Unit], [type], and [install].
Let’s understand these sections in detail.
Access root shell and run the following command.
#cat /usr/lib/systemd/system/sshd.service
This command prints the contents of the /usr/lib/systemd/system/sshd.service file on the terminal.
The following image shows the output of this command.
[Unit]
This section usually contains the Description, Documentation, After, Before, Wants, and Require statements.
Description: - This statement provides a brief description of the unit.
Documentation: - This statement provides the location of the man (help document) page and the command to access the man page.
After: - This statement lists the units which should be activated before this unit.
Before: - This statement lists the units which should be activated after this unit.
The following image explains both the After and Before statements.
Wants: - This statement lists the units/services which should be started before this unit.
Requires: - This statement lists the units/services which must be started before this unit.
Conflicts: - This statement lists the units/services which must be stopped before starting this unit.
Key points
- Systemd starts all units of the system.
- The After/Before statements of a unit define the order in which the unit should be started.
- The Wants/ Requires statements of a unit define the dependencies of the unit.
- Systemd automatically resolves the dependencies and activates the units/services listed in the Wants/Requires statements.
- When activating/starting a unit, systemd first activates/starts the services/units listed in the Wants/Requires statements.
- If the systemd fails to activate the services listed in the Wants statement, it does not stop the process of activating the main unit. It simply starts the unit ignoring the failed services.
- But, if the systemd fails to activate the services listed in the Requires statement, it does not start the main unit.
[Type]
The heading of this section (the keyword between the square brackets) shows the type of the unit. For example, if the unit type is the Service then this section uses the heading [Service] and if the unit type is the Socket then this section uses the heading [Socket]. Statements of this section contain the control operations/commands of the unit.
The common statements that you can find in this section are the following.
ExecStart: - This command starts the unit.
ExecStop: - This command stops the unit.
ExecReload: - This command reloads the unit.
EnvironmentFile: - This statement lists the location of the main configuration file of the unit.
[Install]
This section contains information about the target unit. The most common option that you may see in this section is the following.
WantedBy: - Name of the target unit which starts this unit automatically. For example, if you see the multi-user.target in this statement, then it means when the system enters into the "multi-user.target" target level, this unit is started automatically.
In systemd, a target level is a specific state of the system. In the next part of this article, I will explain the target levels in detail. That’s all for this tutorial. If you like this tutorial, please don’t forget to share it with friends.