systemd Targets and Runlevels: multi-user, graphical, rescue, and emergency

A systemd target is the modern replacement for a SysV init runlevel: it is a unit file (ending in .target) that groups other units into a named system state, such as a text-mode multi-user server or a full graphical desktop. Where SysV init moved between numbered runlevels 0–6, systemd boots into a default target and can switch between targets on the fly with systemctl isolate. The two targets you will boot into most often are multi-user.target (roughly runlevel 3) and graphical.target (roughly runlevel 5), with rescue.target and emergency.target reserved for repair work.

What a target actually is

Under SysV init, a runlevel was a number with a directory of symlinked scripts (/etc/rc3.d/, /etc/rc5.d/) that started or killed services in sequence. systemd throws out the numbered sequence entirely. A target unit contains no start commands of its own — it is a synchronization point. Other units declare relationships to it (WantedBy=multi-user.target, Requires=, After=), and when systemd activates the target, it pulls in everything wired to it, resolving dependencies in parallel rather than running scripts in order.

Targets also stack. graphical.target doesn’t duplicate the work of multi-user.target; it declares Requires=multi-user.target and adds the display manager on top. That layering is why a desktop system passes through the same core state a headless server stops at.

If you want to see how a service gets attached to a target, the WantedBy= line in its [Install] section is the mechanism — covered in more depth in systemd unit files.

The runlevel-to-target map

The exam expects you to translate between the old numbers and the new names without hesitation:

SysV runlevel	systemd target	System state
0	poweroff.target	Shut down and power off
1 (single)	rescue.target	Single-user repair shell, local filesystems mounted, no networking
3	multi-user.target	Full multi-user system, networking, text console only
5	graphical.target	Everything in multi-user plus the graphical login (display manager)
6	reboot.target	Reboot
—	emergency.target	Most minimal state: root filesystem only, mounted read-only

Note that emergency.target has no clean SysV equivalent — it is more stripped-down than old single-user mode ever was. Compatibility symlinks such as runlevel3.target and runlevel5.target still exist and point at the corresponding real targets, and the legacy runlevel command still reports a number, but they are shims for old habits.

Viewing and changing the default target

The default target is what systemd activates at boot, once the kernel and initramfs hand off to PID 1. It is controlled by a symlink at /etc/systemd/system/default.target, but you manage it with systemctl:

systemctl get-default              # show the current default
sudo systemctl set-default multi-user.target
sudo systemctl set-default graphical.target

set-default rewrites that symlink and takes effect at the next boot — it does not change the running system. This is a classic troubleshooting cause: a workstation that used to present a graphical login and now drops to a plain text prompt almost certainly had its default flipped from graphical.target to multi-user.target (an update, an admin saving resources, or a misfired script). systemctl get-default confirms it in one command, and set-default graphical.target plus a reboot fixes it — assuming the display manager service itself is still enabled.

Switching targets on a running system

To change state immediately without touching the default, use isolate:

sudo systemctl isolate multi-user.target   # drop the GUI right now
sudo systemctl isolate graphical.target    # bring it back
sudo systemctl isolate rescue.target       # single-user repair mode
sudo systemctl isolate emergency.target    # bare-minimum shell

isolate starts the named target and stops every unit that isn’t part of its dependency tree. The change lasts only until reboot — the default target is untouched. That distinction (isolate = now and temporary, set-default = persistent and next boot) is exactly what scenario questions probe.

Shortcuts exist for the repair modes: systemctl rescue and systemctl emergency are equivalent to isolating the respective targets, with a wall message to logged-in users. You can also request either mode at boot by appending systemd.unit=rescue.target (or emergency.target) to the kernel command line from the GRUB (GRand Unified Bootloader) edit screen — useful when the system won’t come up normally.

rescue.target vs emergency.target

These two get confused constantly, and the exam exploits that:

• rescue.target is the successor to single-user mode. systemd performs basic initialization, mounts all local filesystems from /etc/fstab, and gives root a maintenance shell (via sulogin, so the root password is required). Networking and multi-user services are not started. Use it for routine repair: fixing a bad service, adjusting configuration, resetting things while filesystems are available.
• emergency.target is far more austere. Only the root filesystem is mounted, and it is mounted read-only; no other filesystems are processed, and essentially nothing beyond the emergency shell is started. It exists for the worst cases — a corrupt /etc/fstab, a filesystem that must not be written before an fsck, a mount loop that hangs boot. To edit files there you first remount root writable: mount -o remount,rw /.

So for a production box that needs an immediate minimal single-user environment with just the root filesystem mounted — say, to repair a broken network configuration file without permanently changing anything — sudo systemctl isolate emergency.target is the precise answer: right state, right now, default untouched.

How the XK0-006 exam tests this

• A translation question: an admin from a SysV background asks what corresponds to runlevel 3 or 5, and you must name multi-user.target / graphical.target — or, asked more abstractly, identify “target” as the systemd concept that replaces runlevels.
• A troubleshooting scenario: a machine that formerly booted to a desktop now stops at a text console, and the expected diagnosis is a default target set to multi-user.target, verified with systemctl get-default.
• A “do it now, don’t make it permanent” scenario steering you to systemctl isolate with the correct repair target — and testing whether you know emergency (root fs only, read-only) from rescue (all local filesystems, basic init).
• A choose-two on accurate statements about rescue.target vs emergency.target, where wrong options swap their properties (e.g., claiming emergency mode mounts all filesystems or starts networking).

Targets fall under the Services and User Management domain — the full XK0-006 study guide lays out all the domains and their weights, and the practice exam bank will surface the rescue-versus-emergency traps until they stop working on you.

Quick reference

• Targets are systemd’s runlevel replacement: named unit groups, not numbered script directories.
• Runlevel 3 → multi-user.target; runlevel 5 → graphical.target; 0 → poweroff.target; 6 → reboot.target.
• systemctl get-default shows the boot target; systemctl set-default <target> changes it persistently (next boot).
• systemctl isolate <target> switches state immediately and temporarily — nothing survives a reboot.
• rescue.target: single-user shell, local filesystems mounted, no networking — routine repairs.
• emergency.target: root filesystem only, read-only, almost nothing running — last-resort repairs; mount -o remount,rw / to write.
• Boot directly into a repair mode with systemd.unit=rescue.target on the kernel command line.
• Text console instead of a desktop? Check the default target before blaming the graphics stack.