systemd — Everything You Need to Know

systemd.md

systemd — Everything You Need to Know

Disclaimer: ChatGPT generated document.

systemd is the dominant init system and service manager on modern Linux distributions. It is much more than “just PID 1” — it is a full userspace platform that manages:

• Boot process
• Services
• Sockets
• Devices
• Mounts
• Logging
• Timers
• Networking
• Resource control (via cgroups)
• Containers (basic)

If you run Debian, Ubuntu, Fedora, Arch, RHEL, SUSE — you are almost certainly running systemd.

---

1️⃣ Historical Context

Before systemd, Linux typically used:

• SysVinit (System V init scripts)
• Upstart (Ubuntu)
• OpenRC (Gentoo, Alpine)

Problems with older init systems:

• Sequential startup
• Shell-script-based
• No dependency graph
• Poor service supervision
• No unified logging
• Weak integration with cgroups

systemd was introduced in 2010 to:

• Enable parallel startup
• Replace fragile shell scripts
• Use declarative unit files
• Integrate tightly with Linux kernel features (cgroups, namespaces, epoll)

It quickly became the standard.

---

2️⃣ Architecture Overview

systemd runs as PID 1.

As PID 1, it:

• Adopts orphaned processes
• Handles signals differently
• Is responsible for system shutdown

But systemd is modular.

It consists of:

• systemd (core init)
• journald (logging)
• logind (session management)
• networkd (network config)
• resolved (DNS)
• timedated
• localed
• hostnamed
• and others

It is essentially a mini operating environment on top of Linux.

---

3️⃣ Core Concept: Units

Everything in systemd is a unit.

Units are defined by text files, typically in:

/etc/systemd/system/
/usr/lib/systemd/system/

---

Types of Units

🔹 Service Units (.service)

Defines a background process.

Example:

nginx.service

---

🔹 Socket Units (.socket)

Implements socket activation.

---

🔹 Target Units (.target)

Logical grouping of units (like runlevels).

Example:

multi-user.target
graphical.target

---

🔹 Mount Units (.mount)

Defines filesystem mount points.

---

🔹 Timer Units (.timer)

Cron replacement.

---

🔹 Path Units (.path)

Triggered by filesystem events.

---

🔹 Device Units (.device)

Kernel device integration.

---

🔹 Scope Units (.scope)

External processes grouped under systemd.

---

4️⃣ Service File Anatomy

Example:

[Unit]
Description=My C++ Server
After=network.target

[Service]
ExecStart=/usr/bin/myserver
Restart=always
User=david
MemoryMax=500M
CPUQuota=50%

[Install]
WantedBy=multi-user.target

Sections:

[Unit]

• Dependencies
• Ordering
• Conditions

[Service]

• Process execution
• Restart policy
• Resource limits
• Sandboxing

[Install]

• Target binding
• Enable/disable behavior

---

5️⃣ Dependency Graph & Parallel Boot

Older init systems:

• Sequential startup

systemd:

• Builds a dependency graph
• Uses aggressive parallelization
• Uses socket activation to defer startup

Boot speed improved significantly.

---

6️⃣ Service Supervision

systemd replaces:

• Monit
• Supervisord
• daemontools

It:

• Tracks main PID
• Restarts on failure
• Applies watchdog
• Applies rate limiting

Restart policies:

Restart=no
Restart=on-failure
Restart=always
Restart=on-abort

---

7️⃣ Logging — journald

systemd includes:

systemd-journald

It:

• Captures stdout/stderr of services
• Stores structured logs
• Supports binary indexed format
• Supports metadata fields (PID, UID, cgroup)

View logs:

journalctl
journalctl -u nginx
journalctl -b
journalctl -f

Advantages:

• Structured
• Indexed
• Integrated with cgroups

---

8️⃣ cgroups Integration

systemd heavily uses Linux cgroups (v2).

Each service runs in its own cgroup:

/sys/fs/cgroup/system.slice/nginx.service

You can set:

MemoryMax=
CPUQuota=
IOWeight=
TasksMax=

This is why systemd is deeply tied to modern Linux.

---

9️⃣ Targets (Replacement for Runlevels)

SysV had runlevels:

• 3 → multi-user
• 5 → graphical

systemd uses targets:

• multi-user.target
• graphical.target
• rescue.target
• emergency.target

Check default:

systemctl get-default

Change:

systemctl set-default multi-user.target

---

🔟 Socket Activation (Very Important)

systemd can:

1. Open sockets before service starts
2. Pass file descriptors to service

Service only starts when connection arrives.

This allows:

• On-demand services
• Faster boot
• Crash-safe restart

Used heavily by:

• D-Bus
• systemd services
• Some container systems

---

1️⃣1️⃣ Timer Units (Cron Replacement)

Instead of:

* * * * * /script.sh

You create:

backup.timer backup.service

Timer example:

[Timer]
OnCalendar=daily
Persistent=true

More powerful than cron:

• Dependency-aware
• Uses monotonic timers
• Integrated logging

---

1️⃣2️⃣ Sandboxing & Security

systemd provides powerful sandboxing options:

ProtectSystem=strict
PrivateTmp=yes
NoNewPrivileges=yes
CapabilityBoundingSet=
RestrictNamespaces=yes
MemoryDenyWriteExecute=yes

This can significantly harden services without containers.

For example, you can:

• Deny filesystem writes
• Block device access
• Remove capabilities
• Restrict syscalls

This is extremely useful for production servers.

---

1️⃣3️⃣ User vs System Instance

There are two systemd modes:

System mode (PID 1)

Manages system services.

User mode

Each user can run:

systemctl --user

User services live in:

~/.config/systemd/user/

Useful for:

• Background desktop apps
• Per-user daemons
• Developer workflows

---

1️⃣4️⃣ logind

systemd-logind

Handles:

• User sessions
• Seats
• Power management
• TTY switching
• Inhibitors (e.g., block shutdown)

Critical for desktop environments.

---

1️⃣5️⃣ networkd & resolved

systemd-networkd

systemd-resolved

They provide:

• Network configuration
• DHCP
• DNS caching
• Split DNS
• VPN-aware DNS

Often used in servers.

---

1️⃣6️⃣ systemd in Containers

In containers:

• Sometimes disabled
• Sometimes used as PID 1
• Works with cgroup delegation

In Kubernetes:

• Usually not used inside pods
• But used on nodes

---

1️⃣7️⃣ Criticism & Controversy

systemd has critics:

Arguments against:

• Too large
• Violates Unix philosophy
• Binary logs (journald)
• Tight coupling to Linux

Arguments for:

• Faster boot
• Unified control
• Strong supervision
• Security features
• Modern architecture

The debate is long-standing in Linux communities.

---

1️⃣8️⃣ Internals

Internally:

• Uses epoll
• Uses event-driven architecture
• Uses D-Bus for IPC
• Uses declarative unit graph resolution
• Maintains state machine per unit

systemd is essentially a dependency-driven state machine engine.

---

1️⃣9️⃣ Debugging & Introspection

Useful commands:

systemctl status
systemctl list-units
systemctl list-dependencies
systemd-analyze blame
systemd-analyze critical-chain

Inspect unit:

systemctl cat nginx

---

2️⃣0️⃣ How It Relates to Your Systems Background

Given your interest in:

• C++
• Systems programming
• Performance
• Resource control

systemd matters because:

• It is the primary interface to Linux service orchestration
• It is deeply integrated with cgroups
• It impacts performance tuning
• It impacts production deployment

If you're writing high-performance C++ services:

• You must understand systemd unit behavior
• Restart policies
• Watchdog integration
• Resource limits
• Signal handling (SIGTERM vs SIGKILL)
• PID 1 signal semantics

---

2️⃣1️⃣ Practical Tips for C++ Developers

1. Always handle SIGTERM properly.
2. Use Type=notify for readiness signals.
3. Use WatchdogSec with sd_notify().
4. Set resource limits via unit file.
5. Use PrivateTmp and ProtectSystem for security.

---

2️⃣2️⃣ Summary

systemd is:

• Linux's dominant init system
• A service manager
• A resource controller (via cgroups)
• A logging framework
• A timer scheduler
• A network manager
• A security sandboxing engine
• A dependency graph resolver

It fundamentally defines how modern Linux systems behave.

---

If you'd like, next I can:

• Deep dive into systemd internals and source architecture
• Show how to integrate a C++ service with sd_notify and watchdog
• Explain how systemd interacts with cgroups at kernel level
• Compare systemd vs OpenRC from an OS architecture perspective
• Walk through writing a production-grade systemd unit for a high-performance C++ server

Given your systems-level interests, we can go very deep.