systemd targets and rescue mode · Linux

systemd targets are collections of units that should reach a particular state together. Targets replace the old SysV runlevels. Knowing which target is right for which recovery is the foundation of every boot-recovery runbook.

The standard targets

Target	Replaces runlevel	Use
`poweroff.target`	0	Halt the system
`rescue.target`	1	Single-user mode with local filesystems mounted
`emergency.target`	–	Root mounted read-only, nothing else started, sulogin root shell
`multi-user.target`	3	Multi-user, no GUI, network up
`graphical.target`	5	Multi-user with GUI
`reboot.target`	6	Reboot

Read-only / Safeactive targets— systemctl list-units --type=target shows every active target. Targets group units — they don't do anything by themselves; they pull in (via Wants=) the units that should reach the active state. The 'current' target is the deepest target the system has reached at boot.

$ systemctl get-default; systemctl list-units --type=target

graphical.target
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Local Encrypted Volumes
getty.target          loaded active active Login Prompts
graphical.target      loaded active active Graphical Interface
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-user System
network.target        loaded active active Network
nss-user-lookup.target loaded active active User and Group Name Lookups
remote-fs.target      loaded active active Remote File Systems
slices.target          loaded active active Slices
sockets.target        loaded active active Sockets
swap.target            loaded active active Active SWAP
sysinit.target        loaded active active Early Sysinit
timers.target         loaded active active Timer
...

Illustrative output

Switching targets at runtime

Service impact possibleisolate— isolate switches to the named target, stopping every unit not in the new target. The system lands at rescue.target — single-user mode, network may be down, all other services stopped. The session becomes a single root shell on the console.

$ sudo systemctl isolate rescue.target

Illustrative output

Service impact possibleisolate to multi-user— Reverse the rescue mode. systemctl daemon-reload is not needed; systemd stops the rescue-only services and starts the multi-user services. Network should come back; SSH may restart.

$ sudo systemctl isolate multi-user.target

Illustrative output

Booting into a specific target

Configuration changeset-default— set-default changes the default.target symlink. The next boot will land in the named target. Use this to switch a server from graphical to multi-user (no GUI) for headless operation.

$ systemctl set-default multi-user.target

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/multi-user.target.

Illustrative output

Kernel command-line overrides

For a one-time boot into a non-default target, append to the kernel command line in GRUB:

systemd.unit=rescue.target

Kernel parameter	Effect
`systemd.unit=rescue.target`	Boot into rescue.target regardless of default
`systemd.unit=multi-user.target`	Boot into multi-user.target
`systemd.unit=emergency.target`	Boot into emergency.target (even less than rescue)
`systemd.unit=rescue.service`	Boot into a single service rather than a target
`init=/bin/bash`	Skip systemd entirely; drop to a shell
`rescue`, `single`, `s`, `S`, `1`	Alias for `systemd.unit=rescue.target`
`emergency`, `-b`	Alias for `systemd.unit=emergency.target`
`2`, `3`, `4`	Alias for `systemd.unit=multi-user.target`
`5`	Alias for `systemd.unit=graphical.target`
`rd.rescue`, `rd.emergency`	The same two states, but entered inside the initrd

single is rescue, not emergency

The legacy SysV name for a minimal boot is single, and it is easy to assume it maps to the most minimal state systemd has. It does not. single, s, S and 1 are all aliases for rescue.target, which pulls in sysinit.target and local-fs.target and mounts everything in /etc/fstab.

That matters when the thing that is broken is local-fs.target

a bad fstab entry, a missing LVM volume, a failing disk. Boot with single and the boot fails again in the same place, and it is easy to conclude that the recovery path itself is broken. The parameter you want in that case is emergency, which mounts only / read-only and starts nothing else.

Use rd.rescue or rd.emergency when the failure happens before the real root is mounted at all, so you need the shell while still inside the initrd.

emergency.target is the last resort

emergency.target is the most minimal state systemd can reach. It sets DefaultDependencies=no, mounts / read-only, starts no other services, and brings up no network.

It does give you a shell. emergency.target has Requires=emergency.service, and emergency.service runs systemd-sulogin-shell emergency on the console with StandardInput=tty-force. You are prompted with “Give root password for maintenance” and land in a root shell. Getting that shell is the entire purpose of the target.

From it, the usual recovery sequence is:

mount -o remount,rw /      # the root filesystem starts read-only
vi /etc/fstab              # or fix LVM, restore a config, remove a unit
journalctl -xb             # read why the boot failed
systemctl reboot

Use emergency.target when the system is so broken that rescue cannot mount filesystems - a bad fstab entry is the classic case, because rescue.target requires local-fs.target and emergency does not.

Procedure for a remote host stuck in a target

Connect via OOB (IPMI, iDRAC, iLO, Redfish console) — SSH may be down
Reboot to GRUB menu — usually Esc, Shift, or F12 depending on firmware
**Press e to edit the kernel command line** of the default entry
**Append systemd.unit=rescue.target** to the linux line (after ro or at the end)
Ctrl-X or F10 to boot the modified entry
At the rescue shell, diagnose. Read-only filesystems are mounted; the journal is available; LVM is available if you load the modules
Fix the problem. Common fixes: remove a unit file, repair a filesystem, restore a config from backup
Reboot with systemctl reboot to return to the default target
Verify with systemctl is-active SERVICE that the affected service is now running.

The standard targets

Switching targets at runtime

Booting into a specific target

Kernel command-line overrides

Procedure for a remote host stuck in a target

Knowledge check