What systemd Actually Is & Why It Replaced init

ws1's own hardening course ran systemctl restart apache2 and systemctl enable fail2ban without ever explaining what those words meant. ansible1-10's own capstone wrapped service: name: fail2ban state: restarted around exactly the same underlying mechanism. bash3 only gestured at it in passing. This course, starting now, is the actual explanation.

PID 1 — The First Process, With a Special Job

When the Linux kernel finishes its own initialization, it starts exactly one process directly: PID 1. Every other process on the system is, eventually, a descendant of it. PID 1 carries a genuinely special responsibility beyond just "the first thing that runs" — it also reaps orphaned processes, adopting them when their original parent process dies, so they never become permanent, un-cleaned-up zombies. On any modern Linux distribution — including Debian, ws1's own target — PID 1 is systemd.

System V init — The Sequential, Runlevel-Based Model

The traditional init system read a sequence of numbered shell scripts (the classic /etc/init.d/, rc.d-style layout), organized into runlevels — 0 for halt, 1 for single-user mode, 3 or 5 for multi-user with or without a graphical environment, 6 for reboot. The real limitation: startup was fundamentally sequential — script N+1 never started until script N finished, even when the two had nothing to do with each other, wasting real boot time waiting on completely unrelated services. Dependencies between services were expressed only informally, through the order scripts happened to be numbered — a fragile convention, not an explicit, checkable relationship.

systemd's Answer — Parallel, Dependency-Based Startup

systemd starts services in parallel wherever genuinely possible, and expresses real dependencies explicitly — previewed here, covered in full in systemd1-4's own Wants/Requires/After/Before material — rather than relying on script-numbering convention. This directly resolves System V init's own sequential-boot cost: independent services no longer wait on each other purely because of where they happened to land in a numbered sequence.

A Concrete Comparison — Booting the Same System, Two Ways

apache2 genuinely does need networking to be up first — that's a real dependency, expressed explicitly. cron has no such requirement, and under systemd it can start the moment its own dependencies are satisfied, without waiting for apache2 or anything else unrelated to finish first.

Hands-On Exercises