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.

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

  • Aggressive parallelisation: 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.
  • 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)
  • 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
  • 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
  • Path-based activation: system services that support path-based activation can be started on-demand when a particular file or directory changes its state
  • 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

systemd introduces the concept of 'systemd units'. These units are represented by unit configuration files, which encapsulate information about the system services, listening sockets and any other objects that are relevant to the init system.

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 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; it is recommended that you avoid using the runlevel command if possible
  • 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. This is not supported by systemd
  • 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
  • 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

Comparison of the service utility with systemctl

service systemctl Description
service <name> start systemctl start <name>.service Starts a service
service <name> stop systemctl stop <name>.service Stops a service
service <name> restart systemctl restart <name>.service Restarts a service
service <name> condrestart systemctl try-restart <name>.service Restarts a service only if it is running
service <name> reload systemctl reload <name>.service Reloads configuration
service <name> status systemctl status <name>.service
systemctl is-active <name>.service 		Checks if a service is running
service --status-all systemctl list-units --type service --all Displays the status of all services


systemctl

Unit Commands (Introspection and Modification)

Command Description
start PATTERN... Start (activate) one or more units specified on the command line
stop PATTERN... Stop (deactivate) one or more units specified on the command line
reload PATTERN... Asks all units listed on the command line to reload their configuration. Note that this will reload the service-specific configuration, not the unit configuration file of systemd
restart PATTERN... Stop and then start one or more units specified on the command line; if the units are not running yet, they will be started
try-restart PATTERN... Stop and then start one or more units specified on the command line if the units are running; this does nothing if units are not running
reload-or-restart PATTERN... Reload one or more units if they support it; if not, stop and then start them instead. If the units are not running yet, they will be started
try-reload-or-restart PATTERN... Reload one or more units if they support it; if not, stop and then start them instead. This does nothing if the units are not running
status [PATTERN] Show terse runtime status information about one or more units, followed by most recent log data from the journal; if no units are specified, show system status. This function is intended to generate human-readable output; if you are looking for computer-parsable output, use show instead. By default, this function only shows 10 lines of output and ellipsises lines to fit in the terminal window. This can be changed with --lines and --full
is-active PATTERN... Check whether any of the specified units are active (i.e. running); returns an exit code 0 if at least one is active, or non-zero otherwise. Unless --quiet is specified, this will also print the current unit state to standard output
is-failed PATTERN... Check whether any of the specified units are in a “failed” state; returns an exit code 0 if at least one has failed, non-zero otherwise. Unless --quiet is specified, this will also print the current unit state to standard output
kill PATTERN... Send a signal to one or more processes of the unit. Use --kill-who= to select which process to kill. Use --signal= to select the signal to send
freeze PATTERN... Freeze one or more units specified on the command line using cgroup freezer. Freezing the unit will cause all processes contained within the cgroup corresponding to the unit to be suspended; being suspended means that unit's processes won't be scheduled to run until thawed
thaw PATTERN... Thaw (unfreeze) one or more units specified on the command line
list-units List units that systemd currently has in memory; this includes units that are either referenced directly or through a dependency, or units that were active in the past and have failed.
By default only units which are active, have pending jobs, or have failed are shown; to list all the units that systemd knows about, use the --all flag. To restrict the units to be shown, use the --type=TYPE and --state=STATE flags
list-timers [PATTERN]... List timer units currently in memory, ordered by the time they elapse next; if one or more PATTERNs are specified, only units matching one of them are shown
list-dependencies [UNIT] Shows units required and wanted by the specified units. This recursively lists units following the Requires=, Requisite=, ConsistsOf=, Wants=, BindsTo= dependencies. By default, only target units are recursively expanded. When --all is passed, all other units are recursively expanded as well
show [PATTERN...] Show properties of one or more units, jobs, or the manager itself; many of the properties shown map directly to configuration settings of the system and service manager and its unit files

Unit File Commands ​

Command Description
list-unit-files [PATTERN...] List unit files installed on the system, in combination with their enablement state (as reported by is-enabled)
enable UNIT...
enable PATH... 		Enable one or more units or unit instances. This will create a set of symlinks, as encoded in the [Install] sections of the indicated unit files; after the symlinks have been created, the system manager configuration is reloaded (in a way equivalent to daemon-reload). Note that this does not have the effect of also starting any of the units being enabled. If this is desired, combine this command with the --now switch, or invoke start with appropriate arguments later
disable UNIT... Disables one or more units; this removes all symlinks to the unit files backing the specified units from the unit configuration directory, and hence undoes any changes made by enable or link. Note that this removes all symlinks to matching unit files, including manually created symlinks
reenable UNIT... Reenable one or more units, as specified on the command line. This is a combination of disable and enable and is useful to reset the symlinks a unit file is enabled with to the defaults configured in its [Install] section
is-enabled UNIT... Checks whether any of the specified unit files are enabled (as with enable). Returns an exit code of 0 if at least one is enabled, non-zero otherwise. Prints the current enable status; to suppress this output, use --quiet. To show installation targets, use --full
mask UNIT... Mask one or more units, as specified on the command line. This will link these unit files to /dev/null, making it impossible to start them. This is a stronger version of disable, since it prohibits all kinds of activation of the unit. This honours the --runtime option to only mask temporarily until the next reboot of the system. The --now option may be used to ensure that the units are also stopped
unmask UNIT... Unmask one or more unit files, as specified on the command line. This will undo the effect of mask
link PATH... Link a unit file that is not in the unit file search paths into the unit file search path. This command expects an absolute path to a unit file. The effect of this may be undone with disable. The effect of this command is that a unit file is made available for commands such as start, even though it is not installed directly in the unit search path. The file system where the linked unit files are located must be accessible when systemd is started
revert UNIT... Revert one or more unit files to their vendor versions. This command removes drop-in configuration files that modify the specified units, as well as any user-configured unit file that overrides a matching vendor supplied unit file
edit UNIT... Edit a drop-in snippet or a whole replacement file if --full is specified, to extend or override the specified unit. Depending on whether --system (the default), --user, or --global is specified, this command creates a drop-in file for each unit either for the system, for the calling user, or for all futures logins of all users
get-default Return the default target to boot into. This returns the target unit name default.target is aliased (symlinked) to
set-default TARGET Set the default target to boot into. This sets (symlinks) the default.target alias to the given target unit

System Commands ​

Command Description
default Enter default mode; this is equivalent to systemctl isolate default.target
rescue Enter rescue mode. This operation is blocking by default, use --no-block to request asynchronous behaviour
halt Shut down and halt the system, after printing a wall message to all users. If combined with --force, shutdown of all running services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the system halt; if --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss
poweroff As per halt, but the system will be powered-off once it has been halted
reboot Shut down and reboot the system


systemd Unit Types

Unit Type File Extension Description
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 recognised 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 organised 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

systemd Unit Files

Unit files contains configuration directives that describe the units and define their behaviour. They can be located in several standard locations including: /usr/lib/systemd/system/ for system units installed by the distribution package manager, /run/systemd/system/ for unit files created at run time, and /etc/systemd/system/ for system units created by the administrator (see systemd.unit(5) for the definitive list of paths).

Unit file names take the following form unit_name.type_extension, where unit_name stands for the name of the unit and type_extension identifies the unit type. For example, there usually is sshd.service as well as sshd.socket unit present on your system. Unit files can be supplemented with a directory for additional configuration files. For example, to add custom configuration options to sshd.service, create the sshd.service.d/custom.conf file and insert additional directives there.

Unit files typically consist of three sections:

  • the [Unit] section: contains generic options that are not dependent on the type of the unit; these options provide unit description, specify the unit's behaviour, and set dependencies to other units
  • the [Unit type] section: if a unit has type-specific directives, these are grouped under a section named after the unit type; for example, service unit files contain the [Service] section
  • the [Install] section: contains information about unit installation used by systemctl enable and disable commands


See RHEL 8, Creating Custom Unit Files or wiki.debian.org/systemd/Services (amongst others) for more information about creating custom unit files.

Important [Unit] section options

Option Description
Description A meaningful description of the unit; This text is displayed, for example, in the output of the systemctl status command
Documentation Provides a list of URIs referencing documentation for the unit
After Defines the order in which units are started. The unit starts only after the units specified in After are active. Unlike Requires, After does not explicitly activate the specified units; the Before option has the opposite functionality to After
Requires Configures dependencies on other units. The units listed in Requires are activated together with the unit; if any of the required units fail to start, the unit is not activated
Wants Configures weaker dependencies than Requires. If any of the listed units do not start successfully, it has no impact on the unit activation. This is the recommended way to establish custom unit dependencies
Conflicts Configures negative dependencies, an opposite to Requires

Important [Service] section options

Option Description
Type Configures the unit process startup type that affects the functionality of ExecStart and related options. One of: simple (the default value, where the process started with ExecStart is the main process of the service); forking (the process started spawns a child process that becomes the main process of the service, and the parent process exits when the startup is complete); oneshot (similar to simple but the process exits before starting subsequent units); dbus (similar to simple, but subsequent units are started only after the main process gains a D-Bus name); notify (similar to simple, but subsequent units are started only after a notification message is sent via the sd_notify() function); and idle (similar to simple, but the actual execution of the service binary is delayed until all jobs are finished)
ExecStart Specifies commands or scripts to be executed when the unit is started. ExecStartPre and ExecStartPost specify custom commands to be executed before and after ExecStart; Type=oneshot enables specifying multiple custom commands that are then executed sequentially
ExecStop Specifies commands or scripts to be executed when the unit is stopped
ExecReload Specifies commands or scripts to be executed when the unit is reloaded
Restart With this option enabled, the service is restarted after its process exits, with the exception of a clean stop by the systemctl command
RemainAfterExit If set to True, the service is considered active even when all its processes exited; default value is False. This option is especially useful if Type=oneshot is configured

Furthermore, some units might have additional configuration options set that define the execution environment of spawned processes. E.g.:

Option Description
ExecSearchPath Takes a colon separated list of absolute paths relative to which the executable used by the Exec* (e.g. ExecStart, ExecStop, etc.) properties can be found. ExecSearchPath overrides $PATH if $PATH is not supplied by the user through Environment, EnvironmentFile or PassEnvironment
WorkingDirectory Takes a directory path relative to the service's root directory specified by RootDirectory, or the special value ~, and sets the working directory for executed processes. If set to ~, the home directory of the user specified in User is used; if not set, defaults to the root directory when systemd is running as a system instance and the respective user's home directory if run as user
RootDirectory Takes a directory path relative to the host's root directory (i.e. the root of the system running the service manager); sets the root directory for executed processes, with the chroot(2) system call
RootImage Takes a path to a block device node or regular file as argument; this call is similar to RootDirectory however mounts a file system hierarchy from a block device node or loopback file instead of a directory
User, Group Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or a numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of systemd --user), the default is root, but User may be used to specify a different user; for user services of any other user, switching user identity is not permitted
SupplementaryGroups Sets the supplementary groups the processes are executed as. This takes a space-separated list of group names or IDs; this option may be specified more than once, in which case all listed groups are set as supplementary groups

See ''systemd.exec(5)'' for more information.

Important [Install] section options

Option Description
Alias Provides a space-separated list of additional names for the unit. Most systemctl commands, excluding systemctl enable, can use aliases instead of the actual unit name
RequiredBy A list of units that depend on the unit; when this unit is enabled, the units listed in RequiredBy gain a Require dependency on the unit
WantedBy A list of units that weakly depend on the unit; when this unit is enabled, the units listed in WantedBy gain a Want dependency on the unit
Also Specifies a list of units to be installed or uninstalled along with the unit
DefaultInstance Limited to instantiated units, this option specifies the default instance for which the unit is enabled


journalctl

The journalctl command is used to query the contents of the systemd journal as written by systemd-journald.service. If called without parameters, it will show the full contents of the journal, starting with the oldest entry collected; if one or more match arguments are passed, the output is filtered accordingly.

Option Description
-a, --all Show all fields in full, even if they include unprintable characters or are very long; by default, fields with unprintable characters are abbreviated as “blob data”
-f, --follow Show only the most recent journal entries, and continuously print new entries as they are appended to the journal
--list-boots Show a tabular list of boot numbers (relative to the current boot), their IDs
-b, --boot[=[ID|all]] Show messages from a specific boot; if the argument is empty, logs for the current boot will be shown
-k, --dmesg Show only kernel messages
--system, --user Show messages from system services and the kernel (with --system); show messages from service of current user (with --user). If neither is specified, show all messages that the user can see
--unit=UNIT|PATTERN Show messages for the specified systemd unit UNIT (such as a service unit), or for any of the units matched by PATTERN; if a pattern is specified, a list of unit names found in the journal is compared with the specified pattern and all that match are used
-S, --since=, -U, --until= Start showing entries on or newer than the specified date, or on or older than the specified date, respectively. Date specifications should be of the format “[YYYY-MM-DD [HH[:MM[:SS]]]]”. If the date component is omitted, the current day is assumed. Alternatively “yesterday”, “today”, “now” and “tomorrow” are understood. Finally, relative times may be specified, prefixed with “-” or “+”, referring to times before or after the current time, respectively
-g, --grep= Filter output to entries where the MESSAGE= field matches the specified regular expression. If the pattern is all lowercase, matching is case insensitive; otherwise, matching is case sensitive. This can be overridden with the --case-sensitive option
--disk-usage Shows the current disk usage of all archived and active journal files
--vacuum-size=, --vacuum-time= Removes the oldest archived journal files until the disk space they use falls below the specified size (specified with the usual “K”, “M”, “G” and “T” suffixes), or all archived journal files contain no data older than the specified timespan (specified with the usual “s”, “m”, “h”, “days”, “months”, “weeks” and “years” suffixes)
--rotate Asks the journal daemon to rotate journal files. Journal file rotation has the effect that all currently active journal files are marked as archived and renamed, so that they are never written to in future. New (empty) journal files are then created in their place. This operation may be combined with --vacuum-size=, --vacuum-time= and --vacuum-file= into a single command


Resources and References

See Also

Related Pages

Red Hat Enterprise Linux-related
Debian
Freedesktop-related
GRUB
Linux-based Terminal Servers
Working with Image Files
  • Last modified: 2022-02-23 16:27
  • by Peter