Menu Close

Chapter 12. Introduction to systemd

systemd is a system and service manager for Linux operating systems. It is designed to be backwards compatible with SysV init scripts, and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, or dependency-based service control logic. Starting with Red Hat Enterprise Linux 7, systemd replaced Upstart as the default init system.

systemd introduces the concept of systemd units. These units are represented by unit configuration files located in one of the directories listed in the following table:

Table 12.1. systemd unit files locations

DirectoryDescription

/usr/lib/systemd/system/

systemd unit files distributed with installed RPM packages.

/run/systemd/system/

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

/etc/systemd/system/

systemd unit files created by systemctl enable as well as unit files added for extending a service. This directory takes precedence over the directory with runtime unit files.

The units encapsulate information about:

  • System services
  • Listening sockets
  • Other objects that are relevant to the init system

The default configuration of systemd is defined during the compilation and it can be found in the systemd configuration file at /etc/systemd/system.conf. Use this file if you want to deviate from those defaults and override selected default values for systemd units globally.

For example, to override the default value of the timeout limit, which is set to 90 seconds, use the DefaultTimeoutStartSec parameter to input the required value in seconds. 

DefaultTimeoutStartSec=pass:_required value_

12.1. systemd unit types

For a complete list of available systemd unit types, see the following table:

Table 12.2. Available systemd unit types

Unit TypeFile ExtensionDescription

Service unit

.service

A system service.

Target unit

.target

A group of systemd units.

Automount unit

.automount

A file system automount point.

Device unit

.device

A device file recognized by the kernel.

Mount unit

.mount

A file system mount point.

Path unit

.path

A file or directory in a file system.

Scope unit

.scope

An externally created process.

Slice unit

.slice

A group of hierarchically organized units that manage system processes.

Socket unit

.socket

An inter-process communication socket.

Swap unit

.swap

A swap device or a swap file.

Timer unit

.timer

A systemd timer.

12.2. systemd main features

The systemd system and service manager provides the following main features:

  • Socket-based activation — At boot time, systemd creates listening sockets for all system services that support this type of activation, and passes the sockets to these services as soon as they are started. This not only allows systemd to start services in parallel, but also makes it possible to restart a service without losing any message sent to it while it is unavailable: the corresponding socket remains accessible and all messages are queued.

    systemd uses socket units for socket-based activation.

  • Bus-based activation — System services that use D-Bus for inter-process communication can be started on-demand the first time a client application attempts to communicate with them. systemd uses D-Bus service files for bus-based activation.
  • Device-based activation — System services that support device-based activation can be started on-demand when a particular type of hardware is plugged in or becomes available. systemd uses device units for device-based activation.
  • Path-based activation — System services that support path-based activation can be started on-demand when a particular file or directory changes its state. systemd uses path units for path-based activation.
  • Mount and automount point management — systemd monitors and manages mount and automount points. systemd uses mount units for mount points and automount units for automount points.
  • Aggressive parallelization — Because of the use of socket-based activation, systemd can start system services in parallel as soon as all listening sockets are in place. In combination with system services that support on-demand activation, parallel activation significantly reduces the time required to boot the system.
  • Transactional unit activation logic — Before activating or deactivating a unit, systemd calculates its dependencies, creates a temporary transaction, and verifies that this transaction is consistent. If a transaction is inconsistent, systemd automatically attempts to correct it and remove non-essential jobs from it before reporting an error.
  • Backwards compatibility with SysV init — systemd supports SysV init scripts as described in the Linux Standard Base Core Specification, which eases the upgrade path to systemd service units.

12.3. Compatibility changes

The systemd system and service manager is designed to be mostly compatible with SysV init and Upstart. The following are the most notable compatibility changes with regards to Red Hat Enterprise Linux 6 system that used SysV init:

  • systemd has only limited support for runlevels. It provides a number of target units that can be directly mapped to these runlevels and for compatibility reasons, it is also distributed with the earlier runlevel command. Not all systemd targets can be directly mapped to runlevels, however, and as a consequence, this command might return N to indicate an unknown runlevel. It is recommended that you avoid using the runlevel command if possible.
    For more information about systemd targets and their comparison with runlevels, see Working with systemd targets.
  • The systemctl utility does not support custom commands. In addition to standard commands such as start, stop, and status, authors of SysV init scripts could implement support for any number of arbitrary commands in order to provide additional functionality. For example, the init script for iptables could be executed with the panic command, which immediately enabled panic mode and reconfigured the system to start dropping all incoming and outgoing packets. This is not supported in systemd and the systemctl only accepts documented commands.
  • The systemctl utility does not communicate with services that have not been started by systemd. When systemd starts a system service, it stores the ID of its main process in order to keep track of it. The systemctl utility then uses this PID to query and manage the service. Consequently, if a user starts a particular daemon directly on the command line, systemctl is unable to determine its current status or stop it.
  • systemd stops only running services. Previously, when the shutdown sequence was initiated, Red Hat Enterprise Linux 6 and earlier releases of the system used symbolic links located in the /etc/rc0.d/ directory to stop all available system services regardless of their status. With systemd , only running services are stopped on shutdown.
  • System services are unable to read from the standard input stream. When systemd starts a service, it connects its standard input to /dev/null to prevent any interaction with the user.
  • System services do not inherit any context (such as the HOME and PATH environment variables) from the invoking user and their session. Each service runs in a clean execution context.
  • When loading a SysV init script, systemd reads dependency information encoded in the Linux Standard Base (LSB) header and interprets it at run time.
  • All operations on service units are subject to a default timeout of 5 minutes to prevent a malfunctioning service from freezing the system. This value is hardcoded for services that are generated from initscripts and cannot be changed. However, individual configuration files can be used to specify a longer timeout value per service, see Changing the timeout limit.