An Introduction to systemd: Features, Concepts, and Usage

systemd is the latest init system for Linux, designed to overcome the limitations of SysVinit and improve boot speed through aggressive parallelization, socket/D‑Bus activation, and on‑demand service start.

It maintains compatibility with existing SysVinit and LSB init scripts, allowing services to run without modification, which reduces migration costs.

Key advantages include faster boot times by launching fewer processes and maximizing parallel execution, as well as providing on‑demand activation so services start only when actually needed, conserving resources.

systemd leverages Linux CGroup features to track and manage the lifecycle of service processes, ensuring clean termination of all related processes without relying on fragile fork‑counting techniques.

It also manages mount points and offers built‑in automount capabilities, replacing the need for external tools like autofs.

Transactional dependency management guarantees that related units start in a consistent order, preventing deadlocks by distinguishing strong (Required) and weak (Wants) dependencies.

Snapshots allow the current state of running services to be saved and later restored, useful for debugging and testing.

systemd includes its own binary journal (journald) that stores logs in a structured format, accessible via journalctl , offering simplicity, low maintenance, portability, performance, minimal resource usage, unified log storage, extensibility, and security.

Fundamental concepts revolve around "units"—configuration objects representing services, sockets, devices, mounts, automounts, swaps, targets, timers, and snapshots. Each unit type has a specific purpose, e.g., .service for daemons, .socket for socket activation, .mount for filesystem mounts, and .target for logical grouping.

Dependencies between units are expressed with keywords such as Requires= , Wants= , After= , etc., allowing systemd to resolve ordering and parallelism.

systemd implements transaction semantics to detect and break circular dependencies, preferring to drop weak (Wants) edges before failing.

Targets replace traditional runlevels, with mappings such as runlevel5.target ↔ graphical.target, enabling flexible system states.

Concurrency is achieved by three mechanisms: pre‑creating sockets so services can start in parallel, using D‑Bus activation to launch services on demand, and integrating autofs‑style on‑access mounting to overlap filesystem preparation with service start.

For developers, writing unit files is essential; an example SSH service unit is shown below:

#cat /etc/system/system/sshd.service
[Unit]
Description=OpenSSH server daemon
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target

Another example demonstrates a mount unit:

#cat sys-kernel-debug.mount
[Unit]
Description=Debug File System
DefaultDependencies=no
ConditionPathExists=/sys/kernel/debug
Before=sysinit.target
[Mount]
What=debugfs
Where=/sys/kernel/debug
Type=debugfs

System administrators use the systemctl command to manage units, with equivalents to traditional SysVinit commands (e.g., systemctl start foo.service , systemctl enable foo.service , etc.). Power management commands such as systemctl reboot , systemctl poweroff , systemctl suspend , and systemctl hibernate are also provided.

The logind component replaces ConsoleKit, handling session tracking, per‑session CGroups, power‑key handling, and multi‑seat support.

Overall, systemd not only replaces init functionality but also integrates many system management tasks—timers, logging, session handling—offering a unified, stable interface that promotes standardization across Linux distributions.