3.5. systemd: Service and System Management
systemd replaced SysVinit as the init system on virtually all major Linux distributions. It's not just a service manager — it's a whole system management suite: logging (journald), hostname management (hostnamectl), time sync (timedatectl), DNS resolution (systemd-resolved), and boot analysis (systemd-analyze). Understanding systemd is non-negotiable for XK0-006.
💡 First Principle: systemd manages units — declarative configuration files that describe a resource (service, timer, mount, socket, device, etc.). A unit file says "here is what this resource is, here is what it depends on, here is how to start and stop it." systemd uses these declarations to build a dependency graph and start units in the correct order, in parallel where possible.
⚠️ Common Misconception (M1): systemctl enable configures boot persistence — it creates a symlink in the appropriate .wants/ directory so the unit is started as part of a target. It does NOT start the service immediately. systemctl start runs the service now but has no effect on the next boot. For both: systemctl enable --now.
Misconfigured or missing systemd units are responsible for services that don't survive reboots, applications that crash silently without restarting, and boot sequences that hang waiting for a service that never starts. Understanding systemd means the difference between a self-healing service and one that requires manual intervention after every restart.
