Setting Up a systemd Service

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 3, “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.

When the RPM packages are installed, systemd unit files reside here.

systemd unit files created at run time. This directory takes precedence over the directory with installed service unit files.

systemd unit files that are created by the systemctl enable command and also unit files added for extending a service. This directory takes precedence over the directory with unit files created at run time.

# systemctl list-units -t service --all

For example:

# systemctl list-units -t service --all
  UNIT                                   LOAD      ACTIVE   SUB     DESCRIPTION>
  accounts-daemon.service                loaded    active   running Accounts Se>
  apache2.service                        loaded    failed   failed  The Apache HTTP server>
\u25cf acpid.service                     not-found inactive dead    acpid.servi>
 after-local.service                    loaded    inactive dead    /etc/init.d>
  alsa-restore.service                   loaded    active   exited  Save/Restor>
  alsa-state.service                     loaded    inactive dead    Manage Soun>
\u25cf amavis.service                    not-found inactive dead    amavis.serv>
  apparmor.service                       loaded    active   exited  Load AppArm>
  appstream-sync-cache.service           loaded    inactive dead    Synchronize>
  auditd.service                         loaded    active   running Security Au>
  augenrules.service                     loaded    active   exited  auditd rule>

# systemctl status --full --lines=50 apache2
  ● apache2.service - Apache HTTP Server
  Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; vendor preset: disabled)
  Active: failed (Result: exit-code) since Fri 2021-08-20 10:24:15 CEST; 2min 24s ago
    Docs: https://httpd.apache.org/docs
 Process: 2491 ExecStart=/usr/bin/apache2 --add-runtime oci=/usr/sbin/apache-runc $DOCKER_NETWORK_OPTIONS $DOCKER_OPTS >
Main PID: 2491 (code=exited, status=1/FAILURE)

In the above example, the service ran as process ID 2491, but failed. Error messages give you a hint on what to do.

#  journalctl --catalog --pager-end --unit=apache2
[...]
  Aug 20 10:24:15 localhost.localdomain dockerd[2479]: unable to configure the Docker daemon with file /etc/apache2/daemon.json:
cannot unmarshal string into Go value of type map[string]interface {}

The option --unit limits the log entries only to the failed Apache2 service. The error message suggests looking into the file /etc/docker/daemon.json. In this scenario, the error was caused by a wrong syntax. You can fix this and restart the Apache2 service.