Chapter 9. Managing Services with systemd
9.1. Introduction to systemd
Table 9.1. Available systemd Unit Types
|Unit Type||File Extension||Description|
|Service unit|| ||A system service.|
|Target unit|| ||A group of systemd units.|
|Automount unit|| ||A file system automount point.|
|Device unit|| ||A device file recognized by the kernel.|
|Mount unit|| ||A file system mount point.|
|Path unit|| ||A file or directory in a file system.|
|Scope unit|| ||An externally created process.|
|Slice unit|| ||A group of hierarchically organized units that manage system processes.|
|Snapshot unit|| ||A saved state of the systemd manager.|
|Socket unit|| ||An inter-process communication socket.|
|Swap unit|| ||A swap device or a swap file.|
|Timer unit|| ||A systemd timer.|
Table 9.2. Systemd Unit Files Locations
| ||Systemd unit files distributed with installed RPM packages.|
| ||Systemd unit files created at run time. This directory takes precedence over the directory with installed service unit files.|
| || Systemd unit files created by |
Overriding the Default systemd Configuration Using system.conf
/etc/systemd/system.conf. Use this file if you want to deviate from those defaults and override selected default values for systemd units globally.
DefaultTimeoutStartSecparameter to input the required value in seconds.
9.1.1. 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.
9.1.2. Compatibility Changes
- 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
runlevelcommand. Not all systemd targets can be directly mapped to runlevels, however, and as a consequence, this command might return
Nto indicate an unknown runlevel. It is recommended that you avoid using the
runlevelcommand if possible.For more information about systemd targets and their comparison with runlevels, see Section 9.3, “Working with systemd Targets”.
systemctlutility does not support custom commands. In addition to standard commands such as
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
iptablesin Red Hat Enterprise Linux 6 could be executed with the
paniccommand, 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
systemctlonly accepts documented commands.For more information about the
systemctlutility and its comparison with the earlier
serviceutility, see Section 9.2, “Managing System Services”.
systemctlutility 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
systemctlutility then uses this PID to query and manage the service. Consequently, if a user starts a particular daemon directly on the command line,
systemctlis 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/nullto prevent any interaction with the user.
- System services do not inherit any context (such as the
PATHenvironment 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 Example 9.21, “Changing the timeout limit”