Understanding Systemd Units: Features and Advantages

Units are the objects that systemd manage. They represent system resources in a standardized way, allowing the suite of daemons to handle them and the provided utilities to manipulate them.

You can think of units as similar to services or jobs in other init systems, but they have a broader definition. Units can represent services, network resources, devices, filesystem mounts, and isolated resource pools.

In other init systems, you might find one unified service definition, but with systemd, you can break these ideas into component units based on their focus. This organization helps you enable, disable, or extend functionality easily, without changing the core behavior of a unit.

Units can easily implement several features, including:

socket-based activation

Breaking out sockets from the daemon itself allows you to handle them separately. This gives you several benefits. For instance, you can delay starting a service until someone first accesses the associated socket. Additionally, you can create all sockets early in the boot process, which lets the system boot the related services at the same time.

path-based activation

You can start a unit based on activity or the availability of specific filesystem paths. This process uses inotify.

device-based activation

You can start units as soon as the necessary hardware is available by using udev events.

bus-based activation

You can activate units on the bus interface that D-Bus provides. When you publish an associated bus, you can start a unit.

implicit dependency mapping

You can build most of the dependency tree for units using systemd. While you can still add your own dependency and ordering information, systemd handle much of the work for you.

instances and templates

You can use template unit files to create several instances of the same general unit. This approach lets you introduce slight variations or sibling units that all serve the same basic function.

easy security hardening

You can enhance security by adding straightforward directives. For instance, you can limit access to certain parts of the filesystem by setting it to no access or read-only. You can also restrict kernel capabilities and assign a private /tmp directory. Additionally, you can manage network access to protect your system further.

drop-ins and snippets

You can easily extend units by providing snippets that override parts of the system’s unit file. This approach allows you to switch between the default and customized unit implementations with ease.

Systemd units offer several advantages over work items in other init systems. This gives you a glimpse of the power you can harness by using native configuration directives.

Types of Units

Systemd organizes units based on the type of resource they represent. You can easily identify the unit type by looking at its type suffix, which is added to the end of the resource name. Here’s a list of the different types of units available in systemd:

.service

A service unit explains how to manage a service or application on the server. It includes instructions on how to start or stop the service when it should start automatically, and information about its dependencies and the order in which related software should run. My primary focus was on .service units, given their practicality and the regularity with which administrators had to manage them.

.socket

Socket unit files in systemd define network/IPC sockets or FIFO buffers for socket-based activation. Each has a linked .service file that starts when the defined socket becomes active.

.path

This unit sets a path for path-based activation. By default, when the path reaches the specified state, a .service unit with the same base name will start. It uses inotify to watch for changes in the path.

.device

A unit describes a device that udev or the sysfs filesystem assigns for systemd management. Not every device will have .device files. However, you might need .device units in certain situations, like when ordering, mounting, or accessing devices.

.automount

An .automount unit sets up a mount point that will mount automatically. You need to name these units after the mount point they refer to, and they must have a matching .mount unit that specifies the details of the mount.

.swap

This unit explains swap space on your system. You should name these units based on the device or file path of the space.

.scope

Scope units are automatically created by systemd based on information it receives from its bus interfaces. You can use these units to manage groups of system processes that are created from outside the system.

.target

A target unit helps you create synchronization points for other units during boot-up or when changing states. You can also use it to move the system to a new state. Other units define their relationship with targets to align with the target’s operations.

.mount

This unit sets up a mount point on your system that systemd will manage. You name it based on the mount path, replacing slashes with dashes. You can also create units automatically from entries in /etc/fstab.

.timer

A .timer unit sets up a timer that systemd manages, similar to how a cron job works for scheduling tasks. When the timer reaches its set time, it starts the matching unit.

.snapshot

A .snapshot unit is created automatically when you run the systemctl snapshot command. This unit helps you restore your system to its current state after making changes. Keep in mind that snapshots do not last across sessions; they only serve to roll back temporary states.

.slice

A .slice unit connects to Linux Control Group nodes, which help you restrict or assign resources to processes linked with that slice. The name shows its position in the cgroup tree. By default, units go into specific slices based on their type.

Where the Systemd Unit Files Stored

You'll find the files that define systemd's unit handling in various locations, each with different priorities and implications.

The system's copy of unit files are typically stored in /lib/systemd/system. Software installations place unit files here by default. These files can be started and stopped on-demand during a session. They're generic, vanilla unit files, often created by upstream project maintainers to work on any standard systemd implementation. Don't edit these files directly. Instead, override them using another unit file location with higher precedence.

To modify unit functions, use the /etc/systemd/system directory. Unit files here take precedence over all other locations. For altering the system's copy of a unit file, placing a replacement here is the safest and most flexible option.

To change certain settings from the system's unit file, you can add snippets in a designated subdirectory. First, create a folder named after the unit file with .d added (for instance, example.service.d for example.service). Inside this folder, make a file that ends with .conf to modify or supplement the system's unit file properties.

Run-time unit definitions are located at /run/systemd/system. These files have priority between those in /etc/systemd/system and /lib/systemd/system. The systemd process uses this location for dynamically created unit files at runtime. You can use this directory to alter unit behavior for the duration of the session, but changes here are lost upon server reboot.

This multi-layered approach allows for flexible configuration and overriding of systemd units across different system levels and use cases.

Structure of a Unit File

Unit files have an internal structure made up of sections. You can identify each section by the square brackets “[” and “]” that surround the section name. Each section continues until you reach the next section or the end of the file.

Section names are specific and case-sensitive. For example, the section [Unit] will not be recognized correctly if you write it as [UNIT]. If you want to include non-standard sections that other applications can read, you can add an X- prefix to the section name.

Inside these sections, you define unit behavior and metadata using simple directives. You can use a key-value format, where an equal sign shows the assignment, like this:

[Section]

Directive1=value

Directive2=value

Directive3=value

When you have an override file, like those found in a unit.type.d directory, you can reset directives by setting them to an empty string. For instance, the system’s version of a unit file might have a directive that looks like this:

Directive1=default_value

You can remove the default_value in an override file by referencing Directive1 without providing a value, like this:

Directive1=

Systemd makes it easy for you to configure your system in a flexible way. You can use different boolean expressions like 1, yes, on, and true for "yes," and 0, no, off, and false for "no." You can also input times in various formats. When you provide a unit-less value, it assumes seconds, and it can combine multiple formats automatically.

Unit Section Instructions

The first section in most unit files is the [Unit] section. You use this section to define metadata for the unit and to set up its relationship with other units.

Even though systemd does not care about the order of sections when reading the file, you usually place this section at the top because it gives a clear overview of the unit. Here are some common directives you will find in the [Unit] section:

Description=

This instruction helps you define the unit's name and its basic function. Various systemd tools will display this, so it's best to make it brief, clear, and useful.

Documentation=

This directive lists URIs for documentation. These can include internal man pages or web URLs. When you run the systemctl status command, you'll see this information, making it easy to find the documentation you need.

Conflicts=

You can use this to identify units that cannot run simultaneously with the current unit. If you start a unit with this relationship, it will stop the other units.

Requires=

When this unit is activated, it relies on certain other units. If those units don't activate successfully, this one won't work either. By default, these required units start at the same time as this one.

Wants=

This directive is like Requires=, but not as strict. When this unit is activated, systemd will try to start any units listed here. If these units aren't found or fail to start, the current unit will keep running. This is typically the best way to set up most dependency relationships. Similar to Requires=, this means units will activate at the same time unless other directives change this behavior.

BindsTo=

This directive works like Requires=, but it also makes sure the current unit stops if the associated unit ends.

Condition...=

You can use several directives beginning with "Condition" to check specific conditions before starting a unit. This way, you can create a general unit file that only runs on suitable systems. If the condition isn't met, the unit will be skipped without any errors.

Assert...=

These directives, much like those beginning with "Condition," examine various elements of the running environment to determine if the unit should activate. However, if these directives return a negative result, it leads to a failure, unlike the "Condition" directives.

Before=

The units outlined in this directive will not initiate until the current unit is indicated as started, provided they are activated at the same time. This does not establish a dependency relationship, so if you require that, you should combine it with one of the earlier directives.

After=

The units mentioned in this directive must begin before your current unit starts. However, this doesn't mean there's a dependency. If you need one, you'll have to establish it using the directives above.

Install Section Instructions

On the opposite side of a unit file, you often find the optional [Install] section. This section defines what happens to a unit when you enable or disable it. When you enable a unit, you mark it to start automatically at boot. You achieve this by linking the unit to another unit that is set to start at boot.

This section will only appear for units that can be enabled. The directives contained within specify the actions the system should take when the unit is enabled, as listed below:

WantedBy=

The WantedBy= directive is a typical method for indicating how a unit should be enabled. This directive establishes a dependency relationship, much like the Wants= directive in the [Unit] section. The main distinction is that this directive is found in the auxiliary unit, which helps keep the primary unit more organized.

When you enable a unit with this directive, it creates a directory in /etc/systemd/system named after the specified unit, with .wants added to the end. Inside this directory, you will find a symbolic link to the current unit, establishing the dependency. For example, if your current unit has WantedBy=multi-user.target, it will create a directory called multi-user.target.wants in /etc/systemd/system (if it doesn’t already exist) and place a symbolic link to the current unit inside it. When you disable this unit, it removes the link and the dependency relationship.

RequiredBy=

This directive works much like the WantedBy= directive, but it sets a necessary dependency that will cause the activation to fail if not satisfied. When you enable it, a unit with this directive will generate a directory that ends with .requires.

Alias=

This rule lets you activate the unit under a different name. This is useful because it enables multiple versions of a function to be available. As a result, related units can search for any provider with the shared, aliased name.

Also=

You can enable or disable units as a group with this directive. List any supporting units that should always be active when this unit is in use. They will be handled together during installation tasks.

DefaultInstance=

If later you encounter template units that generate unit instances with names that can't be predicted, you can rely on this as a default name if no suitable name is given.

Directives for Unit-Specific Sections

You will likely find sections specific to each unit type between the previous two sections. Most unit types provide directives that apply only to them, and you can find these in sections named after each type. We will briefly cover these here.

The device, target, snapshot, and scope unit types do not contain any directives specific to their units, so they do not have individual sections dedicated to their type.

Let's take a quick look at the unit-specific directives for the categories that do have them:

[Service]

The configuration for service-specific parameters is contained within the [Service] block. A key element to define here is the service's Type, which classifies it based on its process behavior and how it runs as a daemon. This classification is crucial, as it guides systemd in properly handling the service and accurately determining its status.

The Type= field can be assigned various values, including:

simple

The service's main operation is defined in the start line. This happens by default if you haven't set the Type= and Busname= directives but you have specified the ExecStart=. For any communication needs, manage it outside this unit using another suitable unit, such as a .socket unit if socket communication is required.

forking

This type of service is designed for situations when a service starts a child process and then the parent process exits almost right away. By using this, you inform systemd that the service is ongoing even though the parent process has ended.

oneshot

This type means the process will run for a brief period, and systemd should wait for it to finish before moving on to other tasks. This is the default behavior if Type= and ExecStart= are not specified. It is suitable for one-time tasks.

dbus

When you assign a name to the unit on the D-Bus bus, systemd will then move on to handling the next unit.

notify

You will get a notification once the service has fully started. The systemd process will hold off on moving to other units until this happens.

idle

The service won't start until every job has been sent out.

You might need extra instructions for specific service types. For example:

RemainAfterExit=

This instruction is often applied to the oneshot type. It means that the service remains active even after the process finishes.

PIDFile=

When the service is designated as "forking", you need to specify the file path that will store the process ID (PID) of the main child process to be monitored.

BusName=

Set the D-Bus bus name to the service that will try to acquire it when using the "dbus" service type.

NotifyAccess=

You need to set the socket access for listening to notifications when you choose the “notify” service type. You have three options: “none,” “main,” and “all.” By default, “none” is selected, which means it ignores all status messages. If you pick “main,” it will listen to messages from the main process. Selecting “all” will process messages from every member of the service’s control group.

Up until now, we've covered some essential background details, but we haven't yet explained how to handle our services. Here are the guidelines for doing this:

ExecStart=

You specify the full path and arguments for the command that starts the process. You can only do this once, except for “oneshot” services. If you put a dash “-” in front of the command path, the system will accept non-zero exit statuses without marking the unit activation as failed.

ExecStartPre=

You can use this to add extra commands that will run before the main process starts. You can include these commands multiple times. Remember to specify the full path for each command. If you want to ignore any failures, you can start the command with a “-.”

ExecStartPost=

This has the same qualities as ExecStartPre=, but it specifies commands that you will run after the main process starts.

ExecReload=

To reload the service's configuration, use the necessary command if it's available.

ExecStop=

To stop the service, you need to provide the command. If you don't give this command, the process will be killed immediately when you stop the service.

ExecStopPost=

You can use this to specify commands that should run after the stop command.

RestartSec=

If you enable automatic service restarts, this sets the time you will wait before trying to restart the service again.

Restart=

This section explains when the systemd will try to restart your service automatically. You can set it to options like “always,” “on-success,” “on-failure,” “on-abnormal,” “on-abort,” or “on-watchdog.” Each option will trigger a restart based on how the service stopped.

TimeoutSec=

You can configure how long systemd waits when starting or stopping a service before it considers the service failed or forcefully kills it. You can set different timeouts using TimeoutStartSec= and TimeoutStopSec=.

[Socket]

Socket units are frequently used in systemd configurations because many services use socket-based activation to enhance parallelism and flexibility. Each socket unit must correspond to a service unit that gets activated when there is activity on the socket.

By separating socket management from the service, sockets can be set up early, allowing associated services to start simultaneously. Typically, the socket name will trigger the service with the same name when a connection is made. When the service starts, it receives the socket, enabling it to handle any queued requests right away.

To specify the actual socket, you often use these directives:

ListenStream=

This specifies an address for a stream socket that enables reliable and orderly communication. If you are utilizing services that depend on TCP, it is advisable to select this type of socket.

ListenDatagram=

You define an address for a datagram socket that supports quick, unreliable communication packets. If you use UDP, you should set this socket type.

ListenSequentialPacket=

This defines an address for communication that happens in order and is reliable. It allows for maximum length datagrams while keeping message boundaries intact. You will most often find this in Unix sockets.

ListenFIFO=

You can choose a FIFO buffer instead of a socket, along with the other listening types.

You can find various types of listening directives, but the ones mentioned earlier are the most frequent.

You can also manage other socket features using extra directives:

Accept=

This decides if a new service instance starts for every connection. By default, it's set to false, meaning one instance manages all connections.

SocketUser=

When you use a Unix socket, you can specify who owns the socket. If you don't set this, the root user will own it by default.

SocketGroup=

When using a Unix socket, you can define the group owner of the socket. If you don't set this or the previous option, the root group will be assigned. If you only set the SocketUser=, systemd will look for a corresponding group.

SocketMode=

For Unix sockets or FIFO buffers, you set the permissions on the created entity.

Service=

If the service name doesn't match the .socket name, you can specify the service using this directive.

[Mount]

Mount units help you manage mount points using systemd. They are named based on the directory they control, following a specific translation process.

First, the leading slash is removed. Then, all other slashes are changed to dashes "-". Additionally, any dashes or unprintable characters are replaced with C-style escape codes. This translated name becomes the mount unit's identifier. Moreover, each mount unit automatically depends on the mounts above it in the hierarchy.

Mount units are usually created from /etc/fstab files during boot. For unit definitions that are automatically generated or those you want to define in a unit file, certain directives prove useful.

What=

The complete filesystem location where the resource should be attached.

Where=

Specify the absolute path of the mount point where you will mount the resource. This path should match the unit file name but use standard filesystem notation.

Type=

The type of filesystem used for the mount.

Options=

Provide any necessary mount options. This should be a list separated by commas.

SloppyOptions=

A boolean value indicates if the mount will fail when you use an unrecognized mount option.

DirectoryMode=

If you need to create parent directories for the mount point, you will determine the permission mode for these directories.

TimeoutSec=

Set the time your system will wait before marking the mount operation as failed.

[Path]

A path unit specifies a filesystem path that systemd monitors for changes. You will need an additional unit that triggers when certain actions take place at that path. Systemd detects path activity by utilizing inotify events.

In the [Path] section of a unit file, you can include the following directives:

PathExists=

This directive checks if the specified path exists. If it does, you activate the related unit.

PathExistsGlob=

This also supports file glob expressions to check if a path exists.

PathChanged=

This directive monitors the file path for any changes. If it detects a change while the file is closed, it activates the associated unit.

PathModified=

This monitors changes similar to the previous directive. It activates when you write to a file and also when you close the file.

DirectoryNotEmpty=

This directive lets systemd activate the related unit when the directory becomes non-empty.

Unit=

This specifies the unit you want to activate when the path conditions mentioned earlier are met. If you leave this out, systemd will search for a .service file that has the same base unit name as this unit.

MakeDirectory=

This setting decides whether systemd will create the necessary directory structure for the specified path before it starts monitoring.

DirectoryMode=

If this option is active, you will set the permission mode for any path components that need to be created.

[Automount]

This unit lets an associated .mount unit mount automatically when your system boots up. Like the .mount unit, you must name these units after the path of the translated mount point.

The [Automount] section is straightforward, with just two options available:

Where=

The automount point's absolute path on the filesystem aligns with the filename, but it employs conventional path notation instead of the translated version.

DirectoryMode=

If you need to create the automount point or any parent directories, you will set the permission settings for those path components.

[Swap]

You use swap units to set up swap space on your system. Name the units after the swap file or swap device, following the same filesystem translation discussed earlier.

Just like mount options, you can automatically create swap units from entries in /etc/fstab, or you can set them up using a dedicated unit file.

In the [Swap] section of a unit file, you can include the following directives for configuration:

What=

You can find the absolute path to the swap space, whether it is a file or a device.

Priority=

This requires you to provide an integer that shows the priority of the swap you are setting up.

Options=

You can set any options that are usually found in the /etc/fstab file using this directive instead. Just use a list separated by commas.

TimeoutSec=

The time that the systemd waits for the swap to activate before it considers the operation a failure.

[Timer]

Timer units help you schedule tasks to run at a specific time or after a set delay. They can replace or add to some functions of the cron and at daemons. You need to provide an associated unit that will activate when the timer reaches its limit.

In the [Timer] section of a unit file, you can include some of the following directives:

OnActiveSec=

This directive lets you activate the associated unit based on the .timer unit’s activation.

OnBootSec=

This directive indicates the duration after the system has booted when the related unit should be activated.

OnStartupSec=

This directive relates to when the systemd process started.

OnUnitActiveSec=

You set a timer based on when the related unit was last activated.

OnUnitInactiveSec=

You set the timer based on when you last marked the associated unit as inactive.

OnCalendar=

You can activate the associated unit by specifying an absolute value instead of relying on an event.

AccuracySec=

You use this unit to set how accurately the timer should be followed. By default, the related unit activates within one minute of reaching the timer. The value you choose for this directive will determine the maximum time window for when systemd schedules the activation.

Unit=

This directive lets you specify which unit should activate when the timer ends. If you don't set it, systemd will search for a .service unit that matches this unit's name.

Persistent=

If you set this, systemd will activate the associated unit when the timer becomes active. It will do this if the unit would have been triggered while the timer was inactive.

WakeSystem=

This setting allows you to wake your system from suspend mode when the timer reaches the specified time.

[Slice]

The [Slice] section of a unit file does not include any specific configuration for .slice units. Instead, you can find resource management directives that are also available in several other units.

You can refer to the systemd.resource-control man page for some common directives found in the [Slice] section. These directives are valid in various unit-specific sections:

• [Slice]
• [Socket]
• [Mount]
• [Scope]
• [Service]
• [Swap]

Deriving Individual Units from Template Files

You'll find that template unit files work similarly to regular ones, with a key difference. They give you more flexibility by using the dynamic information that is available when the system runs. This means you can adapt your units on the fly, making them more versatile.

Think of template unit files as blueprints. You create one file, but it can spawn several unique units based on the current system state. This approach saves you time and reduces repetitive work when managing multiple similar units.

By using templates, you're essentially creating a framework that can adjust to different scenarios. This makes your system more efficient and easier to maintain in the long run.

You can identify template unit files by looking for an @ symbol. This symbol appears after the base unit name and before the unit type suffix. For example, a template unit file name might look like this:

 

temp@.service

 

When you create an instance from a template, you place an instance identifier between the @ symbol and the period that marks the beginning of the unit type. For example, you can use the template unit file to create an instance unit that looks like this:

 

temp@instance1.service

 

You’d usually create an instance file as a symbolic link to the template file. The name of the link includes the instance identifier. This way, you can have multiple links with unique identifiers that point back to a single template file.

When you manage an instance unit, systemd looks for a file with the exact instance name you provide on the command line. If it cannot find that file, it will then search for the related template file.

The following are some of the more frequently used specifiers that will be substituted when an instance unit is analyzed with the appropriate information:

%n

Wherever this appears in a template file, you will see the complete unit name inserted.

%N

This is similar to the previous one, but any escaping, like those found in file path patterns, will be reversed.

%p

This refers to the unit name prefix. It is the part of the unit name that appears before the @ symbol.

%P

This is identical to the previous version, but with all escaping inverted.

%i

This refers to the instance name, which is the identifier that comes after the @ in the instance unit. You will often use this specifier because it remains dynamic. By using this identifier, you promote the use of important configuration identifiers. For example, you can use the port where the service will run as the instance identifier. Then, the template can utilize this specifier to set up the port specification.

%I

This specifier is similar to the one above, but with the escaping reversed.

%f

You will see the unescaped instance name or the prefix name, which will start with a /.

%c

This indicates the control group of the unit, excluding the typical parent hierarchy of /sys/fs/cgroup/systemd/.

%u

The name of the user set up to run the unit.

%U

Similar to the previous request, but using a numeric UID in place of the name.

%H

The hostname of your system that runs the unit.

%%

This is utilized to add a literal percentage symbol.

By using the identifiers in a template file, you allow systemd to fill in the correct values when it interprets the template to create an instance unit.

To learn about creating systemd services, starting, stopping, and enabling them, refer to this follow-up article

Conclusion

Systemd simplifies system management by using clear, easy-to-read unit files. You don't need to learn complex scripting languages to understand how services start or how the system boots. Instead, you'll find straightforward declarations that spell out what each unit does when activated.

By splitting functions into separate units, systemd can start things faster in parallel. This approach also keeps settings simple and lets you change or restart some units without disrupting others. As you become familiar with this system, you'll find it gives you more control and flexibility in managing your Linux setup. Mastering units and unit files will make your admin tasks smoother and more efficient.

Meet Aayush, a WordPress website designer with almost a decade of experience who crafts visually appealing websites and has a knack for writing engaging technology blogs. In his spare time, he enjoys illuminating the minds around him.