Introduction to systemd Basics

The first section found in most unit files is the [Unit] section. This section is used to define the metadata of the unit file and configure the relationship of the unit file to other unit files. This section is usually placed at the top because it provides an overview of the unit file.

Sections containing directives that are specific to the respective type. See Section 4, “Unit file types” for a list of available types. Note that the types device, target, snapshot and scope do not have a type-specific section.

This is often the last section in the unit file and is optional. This section is used to define the behavior of a unit file when it is enabled or disabled. When you enable a unit file, it automatically starts at boot. Based on the specific unit, there could be a dependency on other related units to work properly. For example, chrony requires the directives After, Wants, and Before, which are all dependencies for chrony to work with.

Describes how to manage a service or application. This includes how to start or stop the service, reload its configuration file (if applicable), under what conditions the service starts automatically, and the dependency or the hierarchy information for related unit files.

This unit file is automatically created by systemd from the information received from the D-Bus interface and is used to manage sets of system processes that are created externally.

Defines a path for path-based activation. By default, a .service unit file of the same base name is activated. inotify is a kernel API that is used by programs that want to be notified about changes to files.

The systemctl snapshot command automatically creates a .snapshot unit file. This command creates temporary snapshots of the current state of the system. You can modify the current state of the system after making changes. Snapshots are used for rolling back temporary states.

Defines a timer that is managed by systemd. This is similar to a cron job for delayed or scheduled activation. A unit file with the same name, but with file extension .service is started when the timer is reached.

Associate Linux Control Group nodes, which allow resources to be assigned or restricted to any processes associated with the slice. The name indicates the hierarchy within the control group tree. Units are placed in slices by default depending on their type.

Provides synchronization for other units during a boot up or a change in state, or brings the system to a new state. Other units specify their relation to targets in order to sync with the target's operations.

Describes a network, an IPC socket, or a FIFO buffer that systemd uses for socket-based activation. There is an associated .service file that starts when an activity is seen on the socket that this unit defines.

Defines a device that has been designated for systemd management by udev or sysfs file system. Not all devices have the .device file. This unit file is required when ordering, mounting, or accessing a device.

Defines the swap space on the system. The name of the unit file must reflect the device or file path of the space.

Defines a mount point on the system to be managed by systemd. This file is named after the mount path, with the slashes changed to dashes. Entries within /etc/fstab can have units created automatically.

Defines a mount point that is automatically mounted. Name the file after the mount point that it refers to. A matching .mount unit file is required to define the specifics of the mount.

For example, if unit A has Wants=unit B, when unit A is run, unit B runs as well. But if unit B starts successfully or not, does not have an influence on unit A running successfully.

If unit A has Requires=unit B, both units run but if unit B does not run successfully, unit A is deactivated. It does not matter if the processes of unit A would have run successfully.

For example, if unit A has Before=unit B, when both units are run, unit A is executed fully before unit B.

If unit A has After=unit B, when both units are run, unit B is executed fully before unit A.

Boots by default. The default.target file is a symbolic link to the true target file, such as graphical.target for a desktop workstation. For a server, it is usually graphical.target.

Shuts down and powers off the system.

Target unit that pulls the base system and starts a rescue shell session.

Sets up a non-graphical (console) multi-user system.

Uses a graphical multi-user system with network services.

Shuts down and reboots the system.

Before starting or enabling a systemd service, check the syntax of the unit file to ensure there are no errors. For example:

> sudo systemd-analyze verify /etc/systemd/system/my-custom-service.service

The command analyzes the unit file and reports any syntax errors, missing files, or other issues. You must fix any reported issues before enabling and starting the service.

If you experience any issue with a systemd service, check the service's log. For example:

> sudo  journalctl -u my-custom-service.service

The command displays logs for the specified service, including any error messages, warnings, or other relevant information. You can use these logs to identify and fix issues with the service.

If a service is causing issues during the boot process, you can use the systemd-analyze plot command to visualize the boot process and identify issues. For example:

> sudo systemd-analyze plot > boot-plot.svg

The command creates an SVG file called boot-plot.svg that contains a graphical representation of the boot process and potential issues. This includes the start and stop time of each service. You can open this file in an SVG-compatible image viewer or Web browser to analyze services that are causing issues during the boot process.

To find out which services have failed and to inspect the log output:

> sudo systemctl --state=failed

To find out the current runtime status of a service:

> sudo systemctl status SERVICE

If the shutdown or reboot takes long, it could be a service that is not exiting. systemd waits for some time for each service to exit before trying to terminate it. A common issue is a suspended service or a stalled shutdown. To find out, use the following:

> sudo systemctl poweroff
  Failed to power off system via logind: There's already a shutdown or sleep operation in progress

> sudo systemctl list-jobs

You can cancel the running and waiting jobs, and again shut down or reboot:

> sudo systemctl cancel

> sudo systemctl stop systemd-suspend.service

To find out the current runtime status of a service:

> sudo systemctl status SERVICE

Use an absolute path for executable files and required files, such as configuration files or scripts in your systemd unit file. systemd does not rely on the user's environment variables like $PATH to locate files.

Use the ExecReload directive in the [SERVICE] section when you want to define a specific command that should be executed when you reload a service with the systemctl reload command. This is useful for services that can dynamically reload their configuration without a restart.

[Service]
ExecStart=PATH_TO_EXECUTABLE
ExecReload=PATH_TO_RELOAD_SCRIPT

Use the RestartSec directive in the [SERVICE] section when you want to define a delay (in seconds) before the service is restarted after a failure. This is useful for services that require a specified time to release resources or prevent rapid restart loops that can cause high system load.

[Service]
ExecStart=PATH_TO_EXECUTABLE
Restart=on-failure
RestartSec=5

You can disable emergency mode on a remote machine, for example, a virtual machine hosted on Google Cloud. If this mode is enabled, the machine is blocked from connecting to the network. For example:

> sudo systemctl mask emergency.service

> sudo systemctl mask emergency.target