Systemd - System Boot Management

After Linux loads the kernel at boot, the kernel loads the systemd init system, which then loads userspace and starts processes. systemd controls the dependencies between system services and, based on those, achieves parallel service startup during system initialization.

Design

Units

At the core of systemd is the concept of a “unit”. systemd uses declarative statements in configuration files to record startup instructions for each daemon; these configuration files are called Unit files. There are 12 types of Units in total:

  • Service unit: a system service

  • Target unit: a group made up of multiple Units

  • Device Unit: a hardware device

  • Mount Unit: a filesystem mount point

  • Automount Unit: an automount point

  • Path Unit: a file or path

  • Scope Unit: an external process not started by Systemd

  • Slice Unit: a process group

  • Snapshot Unit: a Systemd snapshot, which lets you switch back to a given snapshot

  • Socket Unit: a socket for inter-process communication

  • Swap Unit: a swap file

  • Timer Unit: a timer

An sshd.service is a Unit, and a multi-user.target collection is also a Unit. One of Systemd’s goals is to simplify the interactions between these units, so if you have a program that needs to start running once a certain mount point is created or a certain device is plugged in, Systemd makes it quite easy to get that working correctly.

Core components and libraries

  • systemd is a system and service manager.

  • systemctl is the control program for interacting with Systemd.

  • systemd-analyze is used to determine system boot performance statistics, gathering additional state and tracing information from the system and service manager

systemd uses the Linux kernel’s cgroups subsystem instead of PIDs to track processes, so that even daemons spawned after two forks won’t escape systemd’s control.

Auxiliary components

  • systemd-journald is the daemon responsible for event logging, using a binary file as its log file; system administrators can choose to use systemd-journald, syslog-ng, or rsyslog to record system events.

  • systemd-logind is the daemon that manages user logins; it’s an integrated login manager that replaces the no-longer-maintained ConsoleKit

  • networkd is the daemon that handles network interface configuration

  • timedated is the daemon that controls time settings

  • udevd is the device manager

  • systemd-boot is the boot manager

Usage

systemctl

  • systemctl status shows the system status

  • systemctl list-units lists loaded units

  • systemctl list-units –all lists loaded units (including inactive ones)

  • systemctl list-units –failed lists units that failed to run

  • systemctl list-unit-files shows all installed units — units enabled to autostart are shown in green, those disabled from autostart are shown in red. Units marked static cannot be enabled directly; they are objects other units depend on, and masked means a unit is disabled. All available unit files are stored in the /lib/systemd/system and /etc/systemd/system/ directories (the latter takes priority). In a unit configuration file, you’ll see various options, including the binary to be run (the “ExecStart” line), other conflicting units (units that cannot run at the same time), and units that must be running before this unit executes (the “After” line). Some units have additional dependency options, such as “Requires” (mandatory dependency) and “Wants” (optional dependency).

  • systemctl start activates a unit immediately

  • systemctl stop stops a unit immediately

  • systemctl restart restarts a unit

  • systemctl reload reloads the configuration

  • systemctl status outputs a unit’s status

  • systemctl is-enabled checks whether a unit is configured to autostart

  • systemctl enable makes a unit start automatically at boot; this creates a symlink for the unit and places it in the .wants directory of the current boot target, and these .wants directories live under the /etc/systemd/system folder.

  • systemctl disable cancels a unit’s autostart at boot

  • systemctl mask disables a unit

  • systemctl unmask re-enables a disabled unit

  • systemctl list-dependencies lists all dependencies of a Unit

When controlling units with systemctl, you usually need to use the unit file’s full name, including the extension (e.g. sshd.service). But some units can be referenced with a shorthand form in systemctl.

journalctl

  • journalctl -b outputs the log for the current boot

  • journalctl -b –since=”2016-10-24 16:38” shows logs since 2016-10-24 16:38

systemd-analyze

  • systemd-analyze blame shows the startup time taken by each service

  • systemd-analyze critical-chain shows the boot process flow as a waterfall