A runlevel is a numbered operating state of a Unix-like system that determines which services and processes are running, from a minimal single-user maintenance mode to a full multi-user graphical desktop. In Linux system initialization, runlevels are the core concept of the classic SysVinit init system, where the init process starts and stops services to move the machine from one state to another.
Modern distributions using systemd have replaced runlevels with targets, but the concept remains important. systemd still provides compatibility targets such as runlevel3.target, administrators still type commands like init 6, and many boot loader instructions, documentation pages and certification exams refer to runlevels by number.
How runlevels work in SysVinit
In SysVinit, the kernel starts init as process ID 1, which reads /etc/inittab to find the default runlevel in the initdefault line. Init then runs the scripts associated with that runlevel. Each runlevel has a directory such as /etc/rc3.d containing symbolic links to service scripts in /etc/init.d.
The link names control behavior. Links beginning with K are kill scripts, run with the stop argument, and links beginning with S are start scripts, run with the start argument. A two-digit number after the letter sets the order, so S10network runs before S55sshd. Switching runlevels runs the kill scripts of services not wanted in the new state, then the start scripts of services that are.
Because init processes these scripts one after another, the start order matters: a web server linked as S85 can rely on networking started by S10. The same sequential design is also the main weakness of the model, since a single slow script delays everything that follows and boot times grow with every added service. Distributions later added dependency headers to init scripts, known as LSB headers, so tools could compute the order automatically instead of relying on hand-picked numbers.
The numbering of runlevels was only partly standardized. The table shows the conventional meanings used by Red Hat-style distributions and most documentation.
| Runlevel | Meaning | Typical use |
|---|---|---|
| 0 | Halt | Shutting the system down |
| 1 or S | Single-user mode | Maintenance and recovery with minimal services |
| 2 | Multi-user without network services | Rarely used; full multi-user on Debian |
| 3 | Multi-user with networking, text console | Servers |
| 4 | Undefined | Available for custom configurations |
| 5 | Multi-user with graphical login | Desktops and workstations |
| 6 | Reboot | Restarting the system |
Debian and its derivatives traditionally treated runlevels 2 to 5 as identical full multi-user states, which shows that the numbers carried conventions rather than fixed rules.
Commands for viewing and changing runlevels
Classic commands remain available on most systems, either natively or as systemd compatibility wrappers. They behave similarly, although under systemd they map to target operations internally.
| Command | Effect | Notes |
|---|---|---|
| `runlevel` | Prints previous and current runlevel, such as N 5 | N means no previous runlevel since boot |
| `who -r` | Shows the current runlevel and when it was entered | Reads the utmp record |
| `init 3` or `telinit 3` | Switches to runlevel 3 | Stops services not needed in that state |
| `init 0` | Halts the system | Equivalent to a shutdown |
| `init 6` | Reboots the system | Equivalent to a restart |
A runlevel can also be selected for a single boot through the kernel command line. Appending single or 1 in the GRUB menu boots into maintenance mode, and appending 3 on a desktop system starts a text-only multi-user session, which is useful when the graphical stack is broken.
Runlevels and systemd targets
systemd replaces the fixed set of numbered states with targets, which are units that group other units through dependencies. Targets can be combined and active simultaneously, are named rather than numbered and start services in parallel, while SysVinit runlevels are exclusive and their scripts run sequentially.
| Runlevel | systemd target | Compatibility alias |
|---|---|---|
| 0 | poweroff.target | runlevel0.target |
| 1 | rescue.target | runlevel1.target |
| 2, 3, 4 | multi-user.target | runlevel2.target to runlevel4.target |
| 5 | graphical.target | runlevel5.target |
| 6 | reboot.target | runlevel6.target |
| No equivalent | emergency.target | Even more minimal than rescue mode |
The modern equivalents of runlevel commands are systemctl get-default and systemctl set-default multi-user.target for the default state, and systemctl isolate rescue.target for switching immediately. On the kernel command line, systemd.unit=rescue.target replaces the old numeric argument.
Under systemd, the runlevel command still works but derives its answer from active targets, so the reported number is an approximation. On a system with several targets active at once, the number can hide details that systemctl list-units --type=target shows directly, which makes the target listing the more reliable diagnostic tool.
Runlevels in other init systems
OpenRC, used by Gentoo and Alpine Linux, keeps the runlevel idea but uses named runlevels such as sysinit, boot, default and shutdown. Services are added with rc-update add sshd default, and administrators can create custom runlevels, for example a state without network services for a laptop.
BSD-style init systems historically had no numbered runlevels and distinguished only single-user and multi-user operation. This variety explains why the term is closely tied to the System V tradition rather than to Unix in general.
Common misunderstandings
- Runlevel numbers are not universal: runlevel 2 means different things on different distributions.
- Single-user mode is not automatically secure: without a root password prompt, anyone with console access gains full control.
- Editing /etc/inittab has no effect on systemd systems: the default is set with systemctl set-default.
- Rescue and emergency targets differ: emergency mounts only the root file system, read-only by default.
- Switching runlevels stops services: isolating a lower state on a remote server can cut off the session.
The last point deserves emphasis. Moving a remote server to single-user or rescue mode stops networking and SSH, so it should be done only with out-of-band console access available.
A non-technical view
A runlevel is like a setting on a building’s master switch. One position keeps only the basic lights on for repair work. Another opens all the offices. Another turns everything off.
On a Linux computer, each numbered runlevel decides which programs run. Choosing a runlevel switches the whole system into a mode, such as repair mode, server mode or desktop mode.
A concrete example
A workstation used for video editing stopped showing a login screen after a graphics driver update; the display stayed black at every boot. The technician could not open a terminal from the desktop because the graphical session never started.
At the GRUB menu, the technician edited the boot entry and appended 3 to the kernel line, which systemd maps to multi-user.target. The machine booted to a text login with networking, the technician removed the faulty driver package, reinstalled the previous version and rebooted normally into graphical.target. The whole recovery took about fifteen minutes and avoided reinstalling the operating system.