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:
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 systemsystemd 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 errorsystemd supports SysV init scripts as described in the Linux Standard Base Core Specification, which eases the upgrade path to systemd service units.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 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.
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 possiblesystemctl 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 systemdsystemctl 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 itsystemd starts a service, it connects its standard input to /dev/null to prevent any interaction with the userHOME and PATH environment variables) from the invoking user and their session; each service runs in a clean execution contextinit script, systemd reads dependency information encoded in the Linux Standard Base (LSB) header and interprets it at run time 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>.servicesystemctl 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 |
| 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 |
| 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 |
| 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 |
| 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 |
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:
[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[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[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.
| 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 |
| 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.
| 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 |
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 |