In this lesson, you will learn how systemd acts as the orchestrator of the kernel lifecycle, specifically managing the synchronization between hardware readiness and user-space service initialization.
The Handover Orchestration
Once the initramfs finishes its work and the root filesystem is mounted, the kernel executes systemd as the first process (PID 1). While the kernel manages low-level hardware abstraction and memory, systemd is responsible for "closing the loop" on the boot process. It manages the kernel lifecycle by ensuring that kernel subsystems—such as network stacks, storage drivers, and thermal management—are fully realized and available before dependent services start.
Managing Startup Dependencies
systemd does not just blindly start services; it uses a sophisticated dependency graph that mirrors the state of the kernel. For example, a service that requires a specific kernel feature, such as a loopback device or a mounted filesystem, must wait for the kernel to expose the underlying driver or block device.
We manage this via unit files that define After= or Requires= directives. Consider a service that performs complex BPF program loading:
[Unit]
Description=Load Custom BPF Observability Probes
# Ensure the kernel has finished initializing the BPF subsystem
After=systemd-modules-load.service
# Wait for the virtual filesystem used by BPF to be mounted
RequiresMountsFor=/sys/fs/bpf
[Service]
ExecStart=/usr/bin/bpftool prog load /lib/firmware/probes/net.o /sys/fs/bpf/net_prog
In this case, systemd monitors the status of the kernel’s virtual filesystems and module loaders. It keeps the service in a queued state until the kernel confirms the requested resources are exposed.
If the kernel encounters a condition requiring a reload or if a subsystem fails to initialize, systemd manages the lifecycle by interpreting kernel uevents. It listens for netlink messages—the bridge between the kernel and user space—to trigger unit activations dynamically. When the kernel signals that a new device (like a network interface) is ready, systemd-udevd (a child of systemd) processes the event, allowing the system to transition services from "waiting for hardware" to "active."
By bridging these kernel events into its dependency graph, systemd ensures that user-space services operate in lockstep with the kernel's evolving state.
Key Takeaway: Systemd acts as the bridge between kernel hardware readiness and user-space availability by translating kernel uevents into a synchronized service dependency graph.