Linux Runlevels vs. Boot Targets: What Every Admin Needs to Know

Understanding how Linux boots and what state the system enters is essential for server administrators, developers, and site operators. Over the past two decades the traditional concept of “runlevels” has been largely replaced by “boot targets” under systemd, but both concepts still appear in documentation, troubleshooting scenarios, and migration guides. This article explains the underlying principles, practical operations, and recommended choices so you can manage boot states confidently on VPS instances and physical servers.

Introduction to boot states: why they matter

The boot state determines which services run, which users can log in, and how the system behaves after kernel initialization. For VPS operators, minimal cloud images and containerized workloads, selecting the right boot state improves security, reduces resource usage, and simplifies maintenance. Historically Linux used SysV runlevels; modern distributions increasingly use systemd targets. Knowing the relationship between them is critical when maintaining legacy scripts or dealing with cross-distro environments.

Fundamental concepts

SysV runlevels (classic)

SysV init uses numeric runlevels (0–6) defined in /etc/inittab. Each runlevel maps to scripts stored in /etc/init.d and symlinked from directories like /etc/rc3.d. The common conventions are:

• 0 — halt (shutdown the system)
• 1 — single-user mode (maintenance, no networking)
• 2 — multi-user, non-networked commonly Debian variant
• 3 — full multi-user text mode (traditional server mode)
• 4 — user-definable
• 5 — graphical mode (X11/Wayland display manager)
• 6 — reboot

Transitioning runlevels uses tools like telinit or init (e.g., telinit 3).

systemd targets (modern)

systemd replaces the init process with a unified system manager using units and dependencies. Instead of numbers, systemd uses human-readable target units like multi-user.target or graphical.target. Targets group units and orchestrate boot ordering using dependency relationships.

Common systemd targets:

• poweroff.target — equivalent to runlevel 0 (halt)
• rescue.target — similar to single-user (runlevel 1)
• multi-user.target — multi-user, non-graphical (runlevel 3)
• graphical.target — multi-user with graphical environment (runlevel 5)
• reboot.target — reboot (runlevel 6)
• emergency.target — very early init for recovery (more extreme than rescue)

You query and change targets using systemctl (e.g., systemctl get-default, systemctl set-default multi-user.target, systemctl isolate rescue.target).

How runlevels map to targets

systemd provides backwards compatibility by implementing runlevelN.target aliases and mapping to legacy runlevels. The typical one-to-one mapping is:

• runlevel0.target → poweroff.target
• runlevel1.target → rescue.target
• runlevel2.target → multi-user.target (Debian variation)
• runlevel3.target → multi-user.target
• runlevel4.target → multi-user.target or custom
• runlevel5.target → graphical.target
• runlevel6.target → reboot.target

On systemd systems, invoking legacy tools like runlevel or who -r will still produce meaningful output. However, direct manipulation of SysV scripts is discouraged unless you are maintaining legacy distributions.

Practical operations and examples

Checking current boot state

Use these commands to inspect the boot state on a systemd host:

• systemctl get-default — shows the default target for future boots
• systemctl list-units --type=target — lists active and loaded targets
• systemctl status unit.target — details about a target and its dependencies
• runlevel or who -r — return compatibility runlevel info

Changing the boot state

To change the current state immediately:

• systemctl isolate multi-user.target — switches to text-mode multi-user
• systemctl isolate rescue.target — drops to single-user-like rescue state
• systemctl isolate graphical.target — start services needed for GUI

To change the default for future boots:

• systemctl set-default multi-user.target
• systemctl set-default graphical.target

For emergency recovery from the kernel command line you can append systemd.unit=rescue.target or systemd.unit=emergency.target to the kernel boot parameters in your bootloader (GRUB), providing a quick way to boot into a minimal environment.

Legacy SysV mechanisms

If you use a SysV-style system, edit /etc/inittab to change the default runlevel or use telinit to switch. On distributions that support both, SysV init scripts can be managed by systemd via generator compatibility, but native systemd units are preferred for deterministic behavior.

When to use which: real-world scenarios

Production VPS without GUI

For headless servers (typical VPS workloads), use multi-user.target as the default. It provides full networking and multi-user login without the overhead of display managers. This minimizes resource usage and attack surface.

Maintenance and recovery

When filesystem repairs or root passwords recovery are necessary, rescue.target or emergency.target are appropriate. Use emergency.target for the most minimal environment (single process, no mount propagation), and rescue.target for a slightly fuller environment with basic systemd services started.

Graphical desktops

Choose graphical.target only for systems requiring a local or remote desktop. On servers, avoid it to reduce unnecessary packages and services.

Containers and immutable images

For containers, it’s common to use a minimal init or even bypass systemd entirely. However, if you run full systemd inside a container (for example systemd-nspawn or LXC), set default target to multi-user.target and disable unnecessary sockets that expect real hardware.

Advantages and trade-offs: runlevels vs targets

Determinism and dependency handling: systemd improves determinism by expressing dependencies explicitly in unit files. Targets are simply units that aggregate dependencies, enabling parallel startup and flexible ordering.

Parallelization and performance: systemd starts units in parallel where possible, reducing boot time compared to serial SysV script execution.

Granularity and features: systemd adds advanced features like socket activation, timer units instead of cron, cgroup-based resource control, and snapshotting. This enables more fine-grained control over service startup than SysV runlevels.

Compatibility: systemd includes compatibility targets and support for legacy SysV scripts, but relying on that compatibility can hide best practices. Conversely, administrators familiar with runlevel numbers may find systemd’s concepts more verbose at first.

Security and operational considerations

Boot targets affect attack surface. A default graphical.target often pulls in display managers and additional networking stacks. For production servers, prefer multi-user.target with explicitly enabled services.

When automating infrastructure (Ansible, Terraform, cloud-init), script explicit systemctl commands rather than editing legacy script directories. Ensure your unit files include After= and Requires= directives to avoid race conditions on boot.

Selection and migration guidance

For administrators deciding between legacy runlevels and systemd targets:

• On modern distributions (Fedora, RHEL, Debian, Ubuntu since ~2015), adopt systemd targets as the primary management model.
• For compatibility with older tooling, maintain small wrapper systemd units that call legacy scripts but gradually migrate to native units.
• Choose multi-user.target for servers, graphical.target only when necessary, and use rescue/emergency targets for recovery paths. Document your default target and recovery procedures in runbooks.
• Test target transitions in staging environments (for example, use snapshots on VPS instances) before applying to production.

Summary

Runlevels and targets describe the desired state of a Linux system during and after boot. While SysV runlevels are numeric and script-based, systemd targets are unit-based and support dependency-driven, parallel startup with richer features like socket activation and cgroups. For modern server environments, especially VPS deployments, prefer systemd targets—with multi-user.target as the standard default for headless servers. Use rescue and emergency targets for maintenance, and avoid unnecessary graphical targets on servers to minimize resource use and attack surface.

For hands-on testing, consider provisioning a reliable VPS instance to experiment with targets and recovery scenarios. If you need a US-based VPS to test migrations, snapshots, or resilient staging environments, check out the USA VPS options at https://vps.do/usa/. They provide quick provisioning and snapshot capabilities that make it easy to trial different boot configurations safely.