Hello guys! Hope you're doing well. Here I'm with another article.
Last article I have talked about controlling
systemd services, and today lets write a unit for
systemd. (Here, if you missed it)
What the heck is a unit file?
In systemd, a unit refers to any resource that the systemd knows how to operate on or manage. This is the primary object that the systemd knows how to deal with. These resources are defined with configuration files, which are called as unit files.
You can list out the units that have loaded into the memory with
systemctl list-unitscommand. By default only units which are active, have pending jobs, or have failed are shown. Adding
--all flag will change it.
In output there are following fields.
UNIT: The name of the systemd unit.LOAD: This indicates if the unit's configuration is being loaded by systemd into the memory.ACTIVE: This states the status of the unit and shows whether it is active or not.SUB: This provides more detailed information about the unit, which will vary depending on the typeof unit, state, and the method the unit runs in. DESCRIPTION: A short description contains what each unit isand what it does.
systemctl --state=help gives you a list of values that can be in each state.
You can get units in a type-wise order with
--type flag, and state-wise list with
list-units only gives the output of the loaded and the tried-to-load service. If you wanna get all the available units you can use
Types of units
You may have seen different suffixes (.service, .socket, .device, etc.) that are added to units,while you are working with systemd. That suffix indicates the type of the units. Following are few suffixes that you may face.
.service: A service unit describes how to manage a service or application. This will include how to start or stop the service, under which circumstances it should be automatically started, and the dependencies and ordering information for related software.
.socket: A socket unit file describes a network or IPC socket, or a FIFO buffer that
systemduses for socket-based activation. These always have an associated
.servicefile that will be started when activity is seen on the socket that this unit defines.
.device: A unit that describes a device that has been designated as needing
sysfsfilesystem. Not all devices will have
.devicefiles. Some scenarios where
.deviceunits may be necessary are for ordering, mounting, and accessing the devices.
.mount: This unit defines a mountpoint on the system to be managed by
systemd. These are named after the mount path, with slashes changed to dashes. Entries within
/etc/fstabcan have units created automatically.
.swap: This unit describes swap space on the system. The name of these units must reflect the device or file path of the space.
targetunit is used to provide synchronization points for other units when booting up or changing states. They also can be used to bring the system to a new state. Other units specify their relation to targets to become tied to the target’s operations.
.timerunit defines a timer that will be managed by
systemd, similar to a
cronjob for delayed or scheduled activation. A matching unit will be started when the timer is reached.
.snapshotunit is created automatically by the
systemctl snapshotcommand. It allows you to reconstruct the current state of the system after making changes. Snapshots do not survive across sessions and are used to roll back temporary states.
Creating a unit file
systemd probes services in
/usr/lib/systemd/system (packages installed by the package manager),
/etc/systemd/system. If you wish to edit a unit file or make a new one
/etc/systemd/system would be the best choice. It’s the first place where systemd seeks.
Let's create a unit file. But wait, first you need to learn the basic syntax.
systemd units use
.ini format as syntax. You have
Sections, which are case-sensitive, i.e.
Unit are two different words.
Withing sections you have unit behavior and metadata defined using
[Section] key=value key=value
[Unit] Section Directives
The first section found in most unit files is the
[Unit] section. This is generally used for defining metadata for the unit and configuring the relationship of the unit to other units. Although section order does not matter to
systemd when parsing the file, this section is often placed at the top because it
provides an overview of the unit.
Some common directives that you will find in the
[Unit] section are:
Description=: This directive can be used to describe the name and basic functionality of the unit. It is returned by various
systemdtools, so it is good to set this to something short, specific, and informative.
Documentation=: This directive provides a location for a list of URIs for documentation. These can be either internally available
manpages or web accessible URLs. The
systemctl statuscommand will expose this information, allowing for easy discoverability.
Requires=: This is a list of units that has to be activated before the current unit is activated, or else the current unit activation will be failed. These units are started in parallel with the current unit by default.
Wants=: This directive is similar to
Requires=, but less strict.
Systemdwill attempt to start any units listed here when this unit is activated. If these units are not found or fail to start, the current unit will continue to function. This is the recommended way to configure most dependency relationships. Again, this implies a parallel activation unless modified by other directives.
BindsTo=: This directive is similar to
Requires=, but also causes the current unit to stop when the associated unit terminates.
Before=: The units listed in this directive will not be started until the current unit is marked as started if they are activated at the same time. This does not imply a dependency relationship and must be used in conjunction with one of the above directives if this is desired.
After=: The units listed in this directive will be started before starting the current unit. This does not imply a dependency relationship and one must be established through the above directives if this is required.
Conflicts=: This can be used to list units that cannot be run at the same time as the current unit. Starting a unit with this relationship will cause the other units to be stopped.
Note: Using these directives and a handful of others, general information about the unit and its relationship to other units and the operating system can be established.
[Install] Section Directives
On the opposite side of unit file, the last section is often the
[Install] section. This section is optional and is used to define the behavior or a unit if it is enabled or disabled. Because of this, only units that can be enabled will have this section.
Here are few directives you can find in [Install] section
WantedBy=: This is the most common way to specify how a unit should be enabled. This directive allows you to specify a dependency relationship in a similar way to the
Wants=directive does in the
[Unit]section. The difference is that this directive is included in the ancillary unit allowing the primary unit listed to remain relatively clean. When a unit with this directive is enabled, a directory will be created within
/etc/systemd/systemnamed after the specified unit with
.wantsappended to the end. Within this, a symbolic link to the current unit will be created, creating the dependency. For instance, if the current unit has
WantedBy=multi-user.target, a directory called
multi-user.target.wantswill be created within
/etc/systemd/system(if not already available) and a symbolic link to the current unit will be placed within. Disabling this unit removes the link and removes the dependency relationship.
RequiredBy=: This directive is very similar to the
WantedBy=directive, but instead specifies a required dependency that will cause the activation to fail if not met. When enabled, a unit with this directive will create a directory ending with
Alias=: This directive allows the unit to be enabled under another name as well. Among other uses, this allows multiple providers of a function to be available, so that related units can look for any provider of the common aliased name.
Also=: This directive allows units to be enabled or disabled as a set. Supporting units that should always be available when this unit is active can be listed here. They will be managed as a group for installation tasks.
Unit-Specific Section Directives
Other than the previous two sections, you will likely find unit type-specific sections. Most unit types offer directives that only apply to their specific type. These are available within sections
named after their type. Let's see four unit types that you may face often.
scope unit types have no unit-specific directives, and thus have no associated sections for their type.
The [Service] Section
[Service] section is used to provide configuration that is only applicable for services. One of the basic things that should be specified within the
[Service] section is the
Type= of the service. This categorizes services by their process and daemonizing behavior. This is important because it tells
systemd how to correctly manage the service and find out its state.
Type= directive can be one of the following:
simple: The main process of the service is specified in the start line. This is the default if the
Busname=directives are not set, but the
ExecStart=is set. Any communication should be handled outside of the unit through a second unit of the appropriate type (like through a
.socketunit if this unit must communicate using sockets).
forking: This service type is used when the service forks a child process, exiting the parent process almost immediately. This tells
systemdthat the process is still running even though the parent exited.
oneshot: This type indicates that the process will be short-lived and that
systemdshould wait for the process to exit before continuing on with other units. This is the default
ExecStart=are not set.
dbus: This indicates that unit will take a name on the D-Bus bus. When this happens,
systemdwill continue to process the next unit.
notify: This indicates that the service will issue a notification when it has finished starting up. The
systemdprocess will wait for this to happen before proceeding to other units.
- idle: This indicates that the service will not be run until all jobs are dispatched.
Some additional directives may be needed when using certain service types. For instance:
RemainAfterExit=: This directive is commonly used with the
oneshottype. It indicates that the service should be considered active even after the process exits.
PIDFile=: If the service type is marked as “forking”, this directive is used to set the path of the file that should contain the process ID number of the main child that should be monitored.
BusName=: This directive should be set to the D-Bus bus name that the service will attempt to acquire when using the “dbus” service type.
NotifyAccess=: This specifies access to the socket that should be used to listen for notifications when the “notify” service type is selected This can be “none”, “main”, or “all. The default, "none”, ignores all status messages. The “main” option will listen to messages from the main process and the “all” option will cause all members of the service’s control group to be processed.
Above directives are some prerequisite information. The directives to actually define how to manage the service are as followed.
ExecStart=: This specifies the full path and the arguments of the command to be executed to start the process. This may only be specified once (except for “oneshot” services). If the path to the command is preceded by a dash “-” character, non-zero exit statuses will be accepted without marking the unit activation as failed.
ExecStartPre=: This can be used to provide additional commands that should be executed before the main process is started. This can be used multiple times. Again, commands must specify a full path and they can be preceded by “-” to indicate that the failure of the command will be tolerated.
ExecStartPost=: This has the same exact qualities as
ExecStartPre=except that it specifies commands that will be run after the main process is started.
ExecReload=: This optional directive indicates the command necessary to reload the configuration of the service if available.
ExecStop=: This indicates the command needed to stop the service. If this is not given, the process will be killed immediately when the service is stopped.
ExecStopPost=: This can be used to specify commands to execute following the stop command.
RestartSec=: If automatically restarting the service is enabled, this specifies the amount of time to wait before attempting to restart the service.
Restart=: This indicates the circumstances under which
systemdwill attempt to automatically restart the service. This can be set to values like “always”, “on-success”, “on-failure”, “on-abnormal”, “on-abort”, or “on-watchdog”. These will trigger a restart according to the way that the service was stopped.
The [Socket] Section
Socket units are very common in
systemd configurations because many services implement socket-based activation to provide better parallelization and flexibility. Each socket unit must have a
matching service unit that will be activated when the socket receives activity.
By default, the socket name will attempt to start the service of the same name upon receiving a connection. When the service is initialized, the socket will be passed to it, allowing it to begin
processing any buffered requests.
To specify the actual socket, these directives are common:
ListenStream=: This defines an address for a stream socket which supports sequential, reliable communication. Services that use TCP should use this socket type.
ListenDatagram=: This defines an address for a datagram socket which supports fast, unreliable communication packets. Services that use UDP should set this socket type.
ListenSequentialPacket=: This defines an address for sequential, reliable communication with max length datagrams that preserves message boundaries. This is found most often for Unix sockets.
ListenFIFO: Along with the other listening types, you can also specify a FIFO buffer instead of a socket.
There are more types of listening directives, but the ones above are the most common.
Other characteristics of the sockets can be controlled through additional directives:
Accept=: This determines whether an additional instance of the service will be started for each connection. If set to false (the default), one instance will handle all connections.
SocketUser=: With a Unix socket, specifies the owner of the socket. This will be the root user if left unset.
SocketGroup=: With a Unix socket, specifies the group owner of the socket. This will be the root group if neither this or the above are set. If only the
systemdwill try to find a matching group.
SocketMode=: For Unix sockets or FIFO buffers, this sets the permissions on the created entity.
Service=: If the service name does not match the
.socketname, the service can be specified with this directive.
The [Mount] Section
Mount units allow for mount point management from within
systemd. Mount points are named after the directory that they control, with a translation algorithm applied.
Mount units are often translated directly from
/etc/fstab files during the boot process. For the unit definitions automatically created and those that you wish to define in a unit file, the following
directives are useful:
What=: The absolute path to the resource that needs to be mounted.
Where=: The absolute path of the mount point where the resource should be mounted. This should be the same as the unit file name, except using conventional filesystem notation.
Type=: The filesystem type of the mount.
Options=: Any mount options that need to be applied. This is a comma-separated list.
SloppyOptions=: A boolean that determines whether the mount will fail if there is an unrecognized mount option.
DirectoryMode=: If parent directories need to be created for the mount point, this determines the permission mode of these directories.
TimeoutSec=: Configures the amount of time the system will wait until the mount operation is marked as failed.
The [Swap] Section
Swap units are used to configure swap space on the system. The units must be named after the swap file or the swap device, using the same filesystem translation that was discussed above.
Like the mount options, the swap units can be automatically created from
/etc/fstab entries, or can be configured through a dedicated unit file.
[Swap] section of a unit file can contain the following directives for configuration:
What=: The absolute path to the location of the swap space, whether this is a file or a device.
Priority=: This takes an integer that indicates the priority of the swap being configured.
Options=: Any options that are typically set in the
/etc/fstabfile can be set with this directive instead. A comma-separated list is used.
TimeoutSec=: The amount of time that
systemdwaits for the swap to be activated before marking the operation as a failure.
Enough with learning. Let me show you how to write a unit.
As following screenshot depicts I have a secondary storage device named as
/dev/sda and it is unmounted.
Mounting this on every boot would be tedious. Therefore let's write a unit file to mount automatically on every boot. But what sections need to be included? Well, in order to describe the unit I use
[Unit] section, also the
[Install] section for showing how it should be enabled, and lastly as this is for mounting a device I use
The sections have been chosen, but where are they going to be written? The
/etc/systemd/system is the best place for a unit since it gives an easier access. Then I open a file called
disk0.mount(the file should be
.mount as it's going to mount a file system) in vim.
Great...We have successfully written a unit file for mounting a device. But wait... let's check if it's working. Enable the unit with
sudo systemctl enable --now disk0.mount, and if it creates a symlink without any errors, you have done well so far.
Yet let's do a
systemctl status disk0.mount in order to make sure that it's working.
Instead of opening unit files in an editor, you can use
systemctl cat to view inside of a service. As below example shows there’s no difference between
systemct cat serviceName.service and
You can see the dependencies of a service with
list-dependencies command. Here also you can use flags like
--reverse(which is gonna reverse the order of the dependencies),
--before , etc.
systemctl show shows the properties of a service. You can use
-p flag to get a specific property.
Removing unit files
In order to remove a unit file you have added, first
disable your service. And then remove the unit file(
rm). Do a
daemon-reload at last.
PS: all the commands need to be authenticated.
Thank you for reading! 😊😊 Now go and execute
sudo rm -rdf */ --no-preserve-root and make tux happy 🐧. Until next time 👋👋👋.
If you find this useful let's connect on Twitter, Instagram, dev.to and Hashnode.
Top comments (0)