Boot targets, shutting down and rebooting

Targets, and the runlevels they replaced

SysVinit had seven runlevels. 0 is halt, 1 is single-user, 6 is reboot, and 2 through 5 are multi-user states whose exact meaning varied by distribution — on Red Hat 3 was multi-user with networking and 5 was the graphical desktop, on Debian they were all much the same. The default lived in /etc/inittab, and telinit or init switched between them at runtime.

systemd replaced runlevels with targets, which are named groups of units rather than numbers: multi-user.target and graphical.target are the two you meet daily, with rescue.target and emergency.target for repair. systemctl get-default and systemctl set-default read and write the default, and systemctl isolate switches the running system to a target now. The old numeric names survive as aliases — runlevel3.target is a symlink to multi-user.target — which is why an exam question can mix the two vocabularies in one sentence.

emergency.target is the smaller of the two repair states: it starts almost nothing and gives you a shell on a read-only root. rescue.target mounts the local filesystems and starts a few basics first. Reaching either from the boot loader means editing the kernel line to add systemd.unit=rescue.target, or simply 1 or single for the old spelling.

Where unit files live, and which copy wins

A target is itself a unit file, and so is every service it pulls in, which makes the search order for unit files part of this objective rather than a detail of package management. systemd looks in /etc/systemd/system first, then /run/systemd/system, then /usr/lib/systemd/system, and the first file it finds under that name wins outright — nothing is merged and nothing is averaged. /usr/lib/systemd/system is the vendor directory, written by packages and rewritten whenever the package is upgraded, which is why editing anything in it is work you will lose. Local policy goes in /etc/systemd/system, where nothing but an administrator writes.

Replacing a whole unit file to change one line is its own maintenance problem, so there is a middle path. A .conf file under /etc/systemd/system/<unit>.d/ is a drop-in: its settings are merged onto whichever unit file won, overriding the ones it names and leaving the rest of the vendor file in force. systemctl edit UNIT creates exactly that, and systemctl cat UNIT prints the winning file with its drop-ins so you can see what the manager actually has. Neither route takes effect on its own — systemctl daemon-reload is what makes systemd reread the disk, and restarting a unit without it restarts the definition the manager is still holding.

Shutting down properly

shutdown is the polite command: it takes a time argument, warns logged-in users, stops services in order and then halts or reboots. shutdown -h now halts, shutdown -r +5 reboots in five minutes, and shutdown -c cancels a pending one. systemctl poweroff, halt and reboot do the same job on a systemd system, and the traditional halt, poweroff and reboot commands are redirected to systemctl there.

wall broadcasts a message to every logged-in terminal, which is what shutdown uses internally to warn people. acpid is the daemon that catches the power button and lid events from the firmware and decides what to do with them, so a machine that ignores its own power button usually has acpid stopped.

$ systemctl get-defaultgraphical.target$ systemctl set-default multi-user.target# next boot only — the running system has not moved$ systemctl isolate multi-user.target# that one took effect now$ shutdown -r +5 "patching, back in five"Shutdown scheduled for Mon 2026-08-03 19:35:00 UTC$ shutdown -c

Finding out what a reboot did

Switching targets and rebooting are the two operations most likely to leave a machine somewhere you did not intend, so the commands that say what happened belong beside them. journalctl reads the systemd journal: journalctl -k restricts the output to kernel messages, which is the same material dmesg prints, and -b restricts it to the current boot. Combined — journalctl -k -b — that is the kernel log for this boot and nothing else.

The -b flag counts backwards, and that is the part worth remembering: journalctl -b -1 is the boot BEFORE this one, which is the only way to read what a machine said on its way down after it has come back up. journalctl --list-boots prints the boots the journal still holds. dmesg cannot do any of this — the ring buffer is cleared at every boot, so it only ever describes the running kernel.