Understanding Runlevels and System Boot Targets in Linux

If you’ve ever wondered how Linux knows which services to start when you power on your computer, or why your server boots into a command prompt while your laptop launches a full desktop, you’re thinking about the system’s runlevels and boot targets. These concepts are central to understanding how Linux controls its startup process, manages different modes (like rescue, multi-user, or graphical), and ensures the right services are running for your needs.

Whether you’re a new Linux user or someone managing multiple servers, learning about runlevels and boot targets gives you more control over your system. You’ll be able to boot into safe modes for troubleshooting, save resources on headless servers, or customize your system for specific workloads. This guide takes you step by step through what runlevels and systemd targets are, how they work, and how to use them in real-world scenarios.

The Basics: What Happens When Linux Boots?

When you turn on a Linux system, several things happen in sequence:

• The Boot Loader: The computer’s firmware (BIOS or UEFI) loads the boot loader—typically GRUB—which lets you choose which kernel or operating system to start.
• The Kernel Loads: The selected Linux kernel is loaded into memory. It initializes hardware, mounts the root filesystem, and then starts the “init system.”
• The Init System: The init system is responsible for starting and managing system services, setting up users, and preparing the system for use.

Over time, init systems have evolved. The two most common approaches you’ll see are:

• SysVinit (older): Uses numeric “runlevels.”
• systemd (modern): Uses named “targets.”

Classic SysVinit and Runlevels

What Is a Runlevel?

A runlevel is a preset mode of operation that defines which system services and processes are running. Each runlevel is assigned a number (from 0 to 6), and switching runlevels starts or stops specific groups of services.

Runlevels were originally designed for flexibility. For example, you might boot into a minimal runlevel for system maintenance, or into a graphical runlevel for desktop use.

Common Runlevels and Their Purposes

Runlevel	Standard Purpose
0	Halt/shutdown the system
1	Single-user mode (maintenance/recovery)
2	Multi-user, no networking (rarely used)
3	Multi-user with networking (no GUI)
4	Unused/Custom user-defined
5	Multi-user with GUI (desktop mode)
6	Reboot the system

Notes:

• Not every distribution uses all runlevels or assigns the same meaning to each.
• On Red Hat-based systems, runlevel 5 is the graphical desktop; runlevel 3 is multi-user text mode. On Debian-based systems, runlevels 2-5 are typically the same.

Why Do Runlevels Matter?

• Troubleshooting: If your desktop is crashing, you can boot into runlevel 3 (no GUI) for repairs.
• Servers: Booting into runlevel 3 saves resources by skipping desktop environments.
• Flexibility: You can create custom runlevels for specific workflows.

How to View and Change Runlevels (SysVinit)

Checking the Current Runlevel

To see which runlevel you’re currently in:

runlevel

Typical output:

N 5

The first letter is the previous runlevel (“N” for none if not applicable), and the second is the current one.

Changing Runlevels

You can change runlevels with:

sudo init 3

This command switches to runlevel 3. Be careful: this may stop your graphical interface or other services.

To reboot:

sudo init 6

To shut down:

sudo init 0

Or use the telinit command, which is functionally identical on many systems.

Runlevel Scripts

Each runlevel has its own set of scripts in /etc/rc.d/ or /etc/init.d/. For example, scripts in /etc/rc3.d/ are run when entering runlevel 3.

This approach is less common on modern systems but is still found on older or minimal Linux distributions.

systemd and Boot Targets: The Modern Approach

Most mainstream Linux distributions now use systemd as their init system. Instead of numeric runlevels, systemd uses targets, which are more descriptive and flexible.

What Are systemd Targets?

A target is a group of systemd units (services, sockets, mounts, etc.) that together define a system state. For example, graphical.target includes everything in multi-user.target plus services needed for a graphical desktop.

Benefits of systemd targets:

• Descriptive: Targets have meaningful names (multi-user.target, graphical.target), making them easier to understand.
• Flexible: You can create your own custom targets.
• Parallelization: systemd can start jobs in parallel, making boot faster.

Mapping Runlevels to systemd Targets

Runlevel	systemd Target	Description
0	poweroff.target	Shut down system
1	rescue.target	Single-user mode (maintenance)
3	multi-user.target	Multi-user, no GUI (server mode)
5	graphical.target	Multi-user with GUI (desktop mode)
6	reboot.target	Reboot system

Note: default.target is a symlink to the system’s default target, usually graphical.target or multi-user.target.

Checking and Changing systemd Targets

See Your Current Target

To see which target your system boots into by default:

systemctl get-default

To see active targets:

systemctl list-units --type=target

Change the Current Target (Temporarily)

To switch to multi-user (text-only) mode:

sudo systemctl isolate multi-user.target

This stops the graphical desktop and switches to a command-line environment.

To return to the desktop:

sudo systemctl isolate graphical.target

Change the Default Boot Target (Permanently)

If you want your system to boot into console mode every time:

sudo systemctl set-default multi-user.target

To switch back to the desktop by default:

sudo systemctl set-default graphical.target

Practical Examples and Scenarios

Scenario 1: Troubleshooting a Broken Desktop

Suppose your graphical environment refuses to load after a bad update. Switch to a safe mode for repairs:

1. Boot into recovery or select a kernel from GRUB, press e to edit.
2. On the “linux” line, add: systemd.unit=multi-user.target
3. Boot. Now you’re in a safe, text-only environment.

Alternatively, after login:

sudo systemctl isolate multi-user.target

This lets you repair or reconfigure your desktop environment without interference from the GUI.

Scenario 2: Running a Headless Server

If you’re setting up a server (web server, database, file server), you don’t need the overhead of a desktop environment. Set your default to multi-user mode:

sudo systemctl set-default multi-user.target

This saves system resources and reduces potential vulnerabilities.

Scenario 3: Entering Rescue Mode for Maintenance

If your system won’t boot properly, rescue mode (similar to runlevel 1) is a minimal environment for repairs:

1. At the GRUB menu, select a kernel, press e.
2. Add: systemd.unit=rescue.target
3. Boot. You’ll enter a root shell with only essential services running.

Customizing and Creating Your Own Targets

One of systemd’s greatest strengths is that you can create custom targets. Suppose you want a special mode for system upgrades or testing.

• Create a new target file: Copy an existing target (like multi-user.target) and edit as needed.
• Add or remove specific service units as dependencies.

Switch to your custom target:

sudo systemctl isolate my-custom.target

This approach is powerful for advanced users, letting you tailor your system for specific tasks or maintenance.

How Does systemd Improve Over Runlevels?

• Parallel Service Startup: systemd can start services in parallel, cutting boot times.
• Descriptive Names: Targets like graphical.target are self-explanatory, compared to numeric runlevels.
• Fine Control: You can enable or disable services individually, and create or modify targets.
• Dependencies: systemd understands service dependencies, so critical services start in the right order.
• Unified Management: Use systemctl for all service and target management instead of multiple commands.

Commands Reference: Runlevels and Targets

For SysVinit systems:

• Check runlevel: runlevel
• Change runlevel: sudo init <number> or sudo telinit <number>
• View scripts: /etc/rc#.d/ where # is the runlevel number

For systemd systems:

• Check current target: systemctl get-default
• List units: systemctl list-units --type=target
• Switch targets: sudo systemctl isolate <target>
• Set default target: sudo systemctl set-default <target>
• Rescue mode: sudo systemctl isolate rescue.target

Tips for Managing Runlevels and Targets Safely

• Know your current state. Before making changes, find out which runlevel or target you’re in.
• Avoid unnecessary switching on production systems. Changing targets or runlevels can affect running services.
• Test changes temporarily. Use systemctl isolate before setting a new default with systemctl set-default.
• Make sure you have SSH or console access. Switching away from the GUI can close remote desktop tools, so always test from a terminal or SSH session.
• Document your custom targets. If you create your own, keep notes for future troubleshooting.

Conclusion

Understanding runlevels and system boot targets gives you a deeper insight into how Linux boots, manages services, and adapts to different use cases. While traditional runlevels are part of Linux’s history, systemd targets have taken over on most modern systems, offering more power, flexibility, and ease of use.

With these concepts in hand, you can troubleshoot boot problems, optimize server performance, or customize your system to match your workflow. You’ll be able to switch between interactive desktops, maintenance shells, and headless server modes with just a few commands. Over time, this knowledge will make you a more capable and resourceful Linux user—ready to handle both day-to-day tasks and tricky troubleshooting situations.

Don’t be afraid to experiment in a virtual machine or on a non-critical system. The more you practice, the more natural these concepts become, and the greater control you’ll have over your Linux environment.