Menu

systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system.

Uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. Supports SysV and LSB init scripts and works as a replacement for sysvinit.

Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.

systemctl controls the systemd system and service manager /usr/lib/systemd/systemd. When run as first process on boot (as PID 1), it acts as init system that brings up and maintains userspace services.

systemd.unit a unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd(1), a temporary system state snapshot, a resource management slice or a group of externally created processes.

$ ls {/etc,/run,/usr/lib}/systemd/system/*
# find overridden configuration files
$ systemd-delta systemd/system
# '.include' is no longer supported, use '<uni-name>.type.d/' to include '.conf' files, to be parsed after file it self
$ man systemd.directives
[Unit]
'Before=, After=' Ordering dependencies between units
'Requires=' Units to also activate. Also deactivates when others deactivate (or fail to activate)
'Wants=' Same as 'Requires=' but doesn't deactivate on failure
'Conflicts=' Configures negative requirement dependencies. Independent of 'After=,Before='
'OnFailure=' Units to activate on 'failed'
'ConditionFirstBoot=yes' Used to populate '/etc' on first boot after factory reset
'ConditionPathExists=/path' File existence condition is checked before a unit is started
'AssertXXX=' Same as 'ConditionXXX' but sets unit state to 'failed'
[Install] called exclusively on enable/disable
'RequiredBy=,WantedBy=' On enable adds 'Requires=,Wants=' and creates symblinks '{.requires,.wants}/' to others
'Also=' Additional units to install/uninstall

systemd.target/systemd.special target units do not offer any additional functionality on top of the generic functionality provided by units. They exist merely to group units via dependencies (useful as boot targets), and to establish standardized names for synchronization points used in dependencies between units (e.g.: After=network.target and WantedBy=multi-user.target).

systemd.socket bind service activation to incoming socket connection, for socket-based activation. A service capable of socket activation must be able to receive its preinitialized sockets from systemd, instead of creating them internally. For most services this requires (minimal) patching.

systemd.path bind service activation to file system changes, uses inotify(7).

# for each .path file, a matching .service file must exist
[Path] # used by .path
'PathExists=,PathExistsGlob=,PathChanged=,PathModified=,DirectoryNotEmpty=' Paths to monitor for certain changes, or existence
'Unit=' Overrides unit activated when any of the configured paths changes
'MakeDirectory=,DirectoryMode=' Create directories to watch before watching
$ cat /etc/systemd/system/foo.path
[Path]
PathExistsGlob=/var/crash/*.crash
Unit=foo.service

systemd can also manage services under the user’s control with a per-user systemd instance. On the first login of a user, systemd automatically launches a systemd –user instance, responsible to manage user services. User units should be placed in {~/.config,/etc,/usr/lib}/systemd/user/.

systemd-cgls/systemd-cgtop show control group contents (processes) and their resource usage. control groups are a way to hierarchally group and label processes, and a way to apply resource limits to these groups.

# show which service owns which processes, same as 'systemd-cgls'
$ ps xawf -eo pid,user,cgroup,args
$ systemd-cgtop

# list the started unit files, sorted by time each of them took to start up
$ systemd-analyze blame
# show which units are in the critical points in the startup chain
$ systemd-analyze critical-chain
# same as bootchart
$ systemd-analyze plot > plot.svg
# more detailed version of 'systemd-analyze plot', add this to to kernel line
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart

systemd has its own logging system called the journal; therefore, running a syslog daemon is no longer required. It captures Syslog messages, Kernel log messages, initial RAM disk and early boot messages as well as messages written to STDOUT/STDERR of all services, indexes them and makes this available to the user. It can be used in parallel, or in place of a traditional syslog daemon, such as rsyslog or syslog-ng.

Systemd journal (216) can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs.

Use coredumpctl to retrieve coredumps from the journal. systemd-coredump is used to store core dumps (generated when user program receives fatal signal) in an external file /var/lib/systemd/coredump or journal.

Journal collects all data logged via syslog, kernel logged via printk as well as stdout/stderr of any service. It also as a native API for logging, sd_journal_print with bindings for other languages (erlang, go, python, ruby, …)

binfmt.d registration of additional binary formats for systems like Java, Mono and WINE. At boot, systemd-binfmt.service reads configuration files from the above directories to register in the kernel additional binary formats for executables.

hostnamectl used to query and change the system hostname. Its the client for systemd-hostnamed.service. It distinguishes three different hostnames: the high-level “pretty” hostname (stored in /etc/machine-info) which might include all kinds of special characters (e.g. “Lennart’s Laptop”), the static hostname (stored in /etc/hostname/) which is used to initialize the kernel hostname at boot (e.g. “lennarts-laptop”), and the transient hostname which is a default received from network configuration (not used if a valid static hostname is defined).

localectl used to query and change the system locale and keyboard layout settings. Its a client for the systemd-localed.service that uses /etc/locale.conf. And for systemd-vconsole-setup.service, an early service that uses /etc/vconsole.conf to configure the virtual console (i.e. keyboard mapping and console font).

systemd-networkd is system service that manages networks, virtual network devices and low-level device links, using systemd.network, systemd.netdev and systemd.link files respectively. It detects and configures network devices as they appear, as well as creates virtual network devices. Can run alongside your usual network management (e.g.: netctl).

systemd-resolved (216) implements a caching DNS stub resolver and an LLMNR resolver and responder. Calls the DNS servers in resolved.conf.d, the per-link static settings in .network files, and the per-link dynamic settings received over DHCP. Also generates {/etc,/run/systemd/resolve}/resolv.conf for compatibility.

Use systemd-nspawn to spawn a namespace containers for debugging, testing and building. Its like chroot on steroids. Use a tool like yum, debootstrap, or pacman to set up an OS directory tree suitable as file system hierarchy for systemd-nspawn containers.

systemd-import (219) used to pull and update containers images from Internet (docker). It converts them into brtfs subvolumes/snapshots and makes them available as simple directory trees in '/var/lib/container/' for booting with 'systemd-nspawn'.