What systemd Is
Scope: the mental model. Five minutes here makes
every systemctl command stop looking like incantation.
PID 1
When Linux boots, the kernel starts exactly one program and hands it everything else: PID 1. Whatever runs as PID 1 is the system’s supervisor — it starts the other services, adopts orphaned processes, and reaps dead children so they don't pile up as zombies.
On nearly every modern distribution, PID 1 is systemd. Check yours:
ps -p 1 -o comm=
systemd
That's the whole top of the tree. Everything else — your SSH server, your web app, your shell — descends from it.
Units: the one noun
systemd manages units: named things with a type suffix.
| Unit type | What it is | Example |
|---|---|---|
.service |
A program that runs | sshd.service |
.timer |
A schedule that starts another unit | logrotate.timer |
.target |
A group / milestone ("we've reached multi-user") | multi-user.target |
.mount |
A filesystem mount | home.mount |
.socket |
A listening socket, held open so a service can start on demand | sshd.socket |
.path |
Watches a file/directory, starts a unit when it changes | — |
Ninety percent of mortal life is .service, with
.timer a distant second. This guide follows that ratio.
The three tools
systemctl— the remote control: start, stop, enable, inspect units. (Chapter 3.)journalctl— the log reader: every unit's output lands in the journal, one searchable stream. (Chapter 5.)systemd-analyze— the diagnostician: verifies unit files, shows what slowed the boot, and grades a service's security exposure. (Chapters 4 and 10.)
Why it feels different from scripts
The older way (init scripts) was: a folder of shell scripts, run in numbered order at boot, each forking into the background and leaving a PID file to approximate "is it running." systemd inverted it: you declare what runs in a unit file, and systemd supervises the actual process tree — it knows the real PID, watches it die, captures its output, and can restart it, because it never lost track of it in the first place.
That's the idea to keep: systemd doesn't run scripts and hope; it supervises processes it started. Most of its rules — no double-forking daemons, log to stdout, stop means SIGTERM to the process group — follow from that one decision.