On a systemd host, what is the practical difference between rescue.target and emergency.target, and how do they relate to the old single-user mode?

## The ancestor: single-user mode Traditional Unix had a single-user mode — runlevel 1 on SysV systems — meant for maintenance. Filesystems were mounted, but no multi-user services ran, no network was configured, and only the console was usable. It was where you went to run a filesystem check, reset a forgotten root password, or repair a machine that would not come up cleanly. systemd inherited that idea and split it into two distinct levels, because "maintenance mode" turned out to cover two very different degrees of brokenness. ## rescue.target `rescue.target` is the direct successor of single-user mode. Reaching it means that `sysinit.target` has been reached: early initialisation has run, and the local mounts described in `/etc/fstab` are in place. What is *not* running is everything above that — no networking to speak of, no multi-user services, no display manager. You get one root shell on the console. This is the right level for the ordinary maintenance jobs: repairing a service that is failing at start, examining what happened during a bad boot, resetting credentials, or working on a filesystem that is mounted but idle because nothing else is using it. ## emergency.target `emergency.target` is deliberately the barest thing systemd can offer. It starts essentially nothing: the root filesystem is mounted — very often read-only — and you get a shell. Other local filesystems are not mounted, and none of the normal early setup has necessarily completed. That minimalism is the point. If reaching rescue requires mounting everything in `/etc/fstab`, then a broken entry in `/etc/fstab` makes rescue unreachable — and repairing that entry is exactly what you need to do. Emergency mode is the level below the thing that is broken. ## How you get there From a running system: ```bash systemctl rescue systemctl emergency ``` Both isolate into the corresponding target, which means everything not required by it is stopped. That is disruptive by design and should never be typed casually on a production host. At boot, you edit the kernel command line from the boot loader and append the target you want: ``` systemd.unit=rescue.target systemd.unit=emergency.target ``` The historical arguments `single`, `s` and `1` still work and map to rescue, which is why old runbooks that say "boot into single" still function on a systemd machine. ## sulogin and the root password Both targets present their shell through `sulogin`, which prompts for the root password before handing over a shell. This matters in two directions. It means physical or console access does not automatically grant a root shell if root has a password set. It also means that on distributions where the root account is locked — Ubuntu being the usual example — the prompt cannot be satisfied the normal way, so recovering such a machine takes a different route, typically a dedicated recovery entry in the boot menu or booting from external media. Know which situation your fleet is in *before* you need it at three in the morning. ## The read-only root trap The single most common surprise in emergency mode is opening a file to fix it and finding the filesystem read-only. Nothing is wrong; the root filesystem was simply mounted read-only and nothing has remounted it. The fix is one command: ```bash mount -o remount,rw / ``` After that you can edit `/etc/fstab`, comment out the bad line, and reboot. Note that `mount -a` is not the fix — it attempts to mount everything in fstab, which is the file you are trying to repair. ## Choosing between them A useful heuristic: pick the *highest* level that is still below the breakage. - The machine boots but a service is wrecking it, or you need to work without users and network in the way → rescue. - The machine does not reach a login at all, hangs during mounting, or drops you at a prompt complaining about a failed mount → emergency. If you aim for rescue and it also fails, that failure is itself diagnostic: the problem lies in early initialisation or in the mounts, so drop to emergency. ## What this tests in an interview The question checks whether you have actually recovered a machine rather than only read about it. Someone who has will mention the read-only root and the remount immediately, will know that both modes ask for the root password through sulogin, and will be aware that a locked root account changes the recovery plan entirely.