Without understanding runlevels and targets, you could accidentally boot a server into a graphical desktop mode, wasting resources and potentially breaking automated scripts. This chapter solves that confusion by explaining how Linux decides what to start when you power it on, and how you can control it—a critical skill for the LPIC-1 exam where you must know commands like 'init', 'telinit', and 'systemctl' to manage system states.
Jump to a section
A simple way to picture Runlevels, Targets, and System Initialization
1,000 passengers arrive at an airport terminal building. This terminal has different 'levels'—the Departure Level, Arrival Level, and a Maintenance Level. Each level has a specific purpose: the Departure Level handles boarding, the Arrival Level handles baggage claim, and the Maintenance Level is for servicing the planes. The entire terminal is the Linux system, and each 'level' is a runlevel or a systemd target. Just as arriving at the wrong level means a passenger ends up in baggage claim instead of the gate, setting the wrong default runlevel on Linux can cause the system to boot into a state that doesn't start the network or allow user logins. The terminal manager can switch between levels by directing passengers to different escalators. Similarly, a system administrator can switch between systemd targets using commands like 'systemctl isolate multi-user.target'. The airport also has a standard operating state—Departure Level for active flights—and emergency states like a fire alarm that forces everyone to the ground level. This maps directly to Linux's graphical.target (normal desktop use) and rescue.target (emergency recovery). Just as the terminal's escalators and signs control the flow, the init system (systemd) controls which services start at each target, ensuring the system operates correctly for its given purpose.
When you press the power button on a Linux computer, the kernel (the core of the operating system) loads first. But the kernel is just a brain—it needs instructions on what programs to run next. That's where the 'init system' comes in. The init system is the first process that starts, with PID 1 (Process ID number 1). It's the parent of all other processes. Traditionally, Linux used a system called SysV init (System V initialization), which used numbered 'runlevels'—states like 0 (halt), 1 (single-user mode for maintenance), 2-4 (multi-user with network, but no GUI), 5 (multi-user with GUI), and 6 (reboot). Runlevel 2, 3, and 4 were basically the same in Debian-based systems, but configurable in Red Hat.
Modern Linux distributions have moved to 'systemd' (system daemon), which uses 'targets' instead of runlevels. A target is like a named collection of services to start. For example, 'multi-user.target' starts text-mode interfaces and network services, while 'graphical.target' also starts a desktop environment. The key difference is that systemd targets are more flexible than runlevels—you can have custom targets that start a specific set of services (like 'mail-server.target' just for email).
Common targets you need to know for LPIC-1: - poweroff.target (equivalent to runlevel 0): shuts down the system. - rescue.target (equivalent to runlevel 1): single-user mode, starts minimal services for system repair. - multi-user.target (equivalent to runlevel 2,3,4): non-graphical, multi-user with network. - graphical.target (equivalent to runlevel 5): multi-user with a display manager. - reboot.target (equivalent to runlevel 6): reboots the system. - emergency.target: even more minimal than rescue.target—only a root shell on the console, no network.
How does this work in practice? When systemd starts, it reads its configuration files in /lib/systemd/system/ and /etc/systemd/system/. The default target is set by a symbolic link from /etc/systemd/system/default.target to a target file (e.g., graphical.target). You can change the default target with: 'systemctl set-default multi-user.target'. To switch to a different target immediately, you use: 'systemctl isolate graphical.target'. The 'isolate' command stops all services not needed for the target and starts the ones that are.
Why does this matter? Imagine a server running a web application that needs a graphical desktop to perform automated tests. If you mistakenly boot into graphical.target, the system might allocate memory to a desktop unnecessary for server tasks, slowing down critical services. Or, if a server gets stuck during boot due to a faulty service, you can boot into rescue.target to fix the problem without starting all services.
For LPIC-1, you must also understand the legacy commands: 'init' and 'telinit'. 'init' is the traditional SysV init command that changes runlevels (e.g., 'init 3' switches to runlevel 3). 'telinit' is a symbolic link or wrapper to 'init'. On systemd systems, these are often aliases for 'systemctl isolate' but still accepted. However, the exam focuses on systemd commands. You'll need to know how to list current target: 'systemctl get-default', change default: 'systemctl set-default target', and switch target: 'systemctl isolate target'. Also, understand that runlevels map to targets—runlevel 3 typically maps to multi-user.target, runlevel 5 to graphical.target.
Finally, the boot process itself: BIOS/UEFI loads the bootloader (GRUB), which loads the kernel. The kernel starts systemd (PID 1). systemd reads its default.target and starts all dependent services. If a service fails, systemd can attempt to restart it or continue booting. This is a stark contrast to SysV init which ran scripts one by one in order—systemd parallelises service starts, making boot faster.
Boot the system and observe the default target
When Linux starts, systemd (PID 1) reads the default target from /etc/systemd/system/default.target. On a standard desktop installation, this is graphical.target. You can verify this after boot with 'systemctl get-default'.
List all available targets
Use 'systemctl list-units --type=target' to see all targets on the system. This shows their state (active/inactive) and descriptions. Understanding this list helps you know which states are possible, such as multi-user.target or rescue.target.
Change the default target for next boot
Run 'systemctl set-default multi-user.target' to make the system boot into text mode by default. This is a permanent change. If you later want a GUI, you would set it to graphical.target. This is critical for servers that should not waste resources on a desktop.
Switch to a different target immediately without rebooting
Use 'systemctl isolate multi-user.target' to switch the current system state to text mode. This stops all services not required by multi-user.target (like the display manager). This is useful for performing maintenance without fully shutting down.
Boot into emergency mode via GRUB for recovery
At the GRUB menu, press 'e' to edit boot parameters. Add 'systemd.unit=emergency.target' to the kernel line (or 'single' for single-user runlevel). This gives you a minimal shell to repair the system, useful when filesystem corruption prevents normal boot.
Verify the current target and troubleshoot failures
After booting, run 'runlevel' to see previous and current runlevel (if SysV compatible). Use 'journalctl -xb' to review logs for service failures that may have prevented a target from fully activating. This step isolates issues like a broken DHCP client in multi-user.target.
Sarah is a junior system administrator at a small company that runs an internal web application on a Linux server. One morning, she receives an alert that the server is unreachable. She connects to the console (physical or virtual) and sees the system is stuck at a partial boot—it's in a state where the network isn't working, but the root filesystem is mounted. This is a classic scenario where understanding targets is critical.
Step 1: Sarah interrupts the boot by pressing 'e' in GRUB and adding 'systemd.unit=rescue.target' to the kernel command line. This forces the system to boot into rescue.target, which gives her a root shell without starting network or other services.
Step 2: Once she has the root shell, she checks journalctl (systemd's log viewer) to see what went wrong: 'journalctl -xb'. The logs show that a misconfigured DHCP client service (dhcpcd) is failing and preventing the network from starting in multi-user.target. The failure is causing systemd to enter a dependency loop.
Step 3: Sarah disables the faulty service: 'systemctl disable dhcpcd'. She also checks if she can start the network manually with 'systemctl start networking.service'—it works, meaning the network itself is fine, just the DHCP client was broken.
Step 4: She then reboots the server using 'systemctl reboot', but before that, she want to ensure that multi-user.target is still the default target (so the server boots normally). She runs 'systemctl get-default'—it shows graphical.target, which is wrong for a server. She should change it: 'systemctl set-default multi-user.target'.
Step 5: After reboot, the server reaches multi-user.target, the network starts (with a different DHCP client this time), and the web application is available. Sarah documents the issue and schedules a permanent fix.
What did Sarah do differently because she understood targets? She knew that rescue.target gives her a working shell without dependency on the network. She knew how to change the default target. She used 'journalctl' to read logs, which is part of the systemd ecosystem. Without this knowledge, she might have reinstalled the OS or spent hours guessing. - Real-world actions:
- Checking current target: systemctl get-default - Changing default: systemctl set-default multi-user.target - Switching target: systemctl isolate multi-user.target - Booting into emergency: adding 'systemd.unit=emergency.target' at GRUB - Reading logs: journalctl -xb
This scenario is common in production environments where server configurations drift (someone accidentally installed a GUI on a server, setting the default target to graphical).
The LPIC-1 exam (101.2) is laser-focused on practical commands and understanding the relationship between SysV runlevels and systemd targets. You won't be tested on theory alone—you must know which command to type and what it does. Here's exactly what you need to know:
Exam topics:
Know the mapping between runlevels (0-6) and systemd targets. Specifically: 0 -> poweroff.target, 1 -> rescue.target, 2-4 -> multi-user.target (or a custom target), 5 -> graphical.target, 6 -> reboot.target. Trap: Debian and Ubuntu systems often treat runlevels 2-5 as multi-user (no distinction), while Red Hat uses runlevel 5 for graphical. The exam expects you to know the generic mapping.
Commands: systemctl get-default, systemctl set-default, systemctl isolate, systemctl list-units --type=target (lists all available targets), systemctl list-dependencies (shows required units). Also legacy: init, telinit, runlevel (shows previous and current runlevel).
Understanding 'isolate': This is a systemd verb that starts a target and stops all others. Memory aid: isolate = switch to this target exclusively.
The 'emergency.target' vs 'rescue.target': Emergency gives a minimal shell with root filesystem mounted read-only; rescue.target mounts root read-write and tries to start some services. Exam often tests that emergency.target does not bring up the network.
GRUB modifications: You must know how to boot into a different target at boot time by editing the kernel line (adding 'systemd.unit=rescue.target' or '1' for runlevel 1, or 'single' for single-user mode). Traps: They might ask which parameter to add to GRUB for single-user mode—the answer is often 'single' or '1' on the kernel command line.
Default target configuration: The file /etc/systemd/system/default.target is a symbolic link. You can change it with 'ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target' as an alternative to systemctl set-default.
Trap patterns: 1. They give you a scenario where a GUI is running on a server and ask how to change it to boot to text mode. Answer: systemctl set-default multi-user.target, then reboot or systemctl isolate multi-user.target. 2. They ask which command shows the current default target. Answer: systemctl get-default. Trap: They might list 'runlevel' as an answer—but 'runlevel' shows current runlevel (if compatible), not default target. 3. They ask what runlevel 1 maps to in systemd—trap: Some might think 'single-user.target' but the exact name is 'rescue.target'. Another trap: runlevel 2-5 in systemd is 'multi-user.target' (except 5 which is 'graphical.target'—they might mix up). 4. They present a situation where a system fails to boot fully, and ask which target to use for repair. The best answer is often 'rescue.target' because it gives a writable filesystem and some services, while 'emergency.target' is for when filesystems are corrupted.
Key definitions to memorise:
PID 1: Always systemd (or init on older systems).
target: A collection of services (units) that represent a system state.
isolate: Switch to a target, stopping all others.
default.target: Symbolic link determining boot target.
emergency: Minimal shell, read-only root.
rescue: Shell with writable root and basic services.
poweroff.target = runlevel 0.
reboot.target = runlevel 6.
systemd targets replace SysV runlevels, with common targets being poweroff.target (0), rescue.target (1), multi-user.target (2-4), graphical.target (5), and reboot.target (6).
The default boot target is determined by the symbolic link at /etc/systemd/system/default.target, changeable via 'systemctl set-default' or manual symlink update.
'systemctl isolate' switches the current target immediately, stopping all services not needed for the new target.
emergency.target provides a minimal shell with root filesystem read-only and no network, while rescue.target mounts root read-write and starts basic services.
GRUB boot options such as 'systemd.unit=rescue.target' or 'single' allow you to override the default target during boot for recovery.
The legacy commands 'init', 'telinit', and 'runlevel' still work on most systemd systems, but the exam emphasis is on systemctl for modern management.
These come up on the exam all the time. Here's how to tell them apart.
runlevel
Numeric (0-6) with fixed meanings
Used by SysV init (older systems)
Change via 'init' or 'telinit' commands
systemd target
Named (e.g., multi-user.target)
Used by systemd (modern systems)
Change via 'systemctl isolate' command
rescue.target
Mounts root filesystem read-write
Starts some basic services like networking
Equivalent to runlevel 1
emergency.target
Mounts root filesystem read-only
Starts only a minimal shell, no network
More minimal than rescue; used for filesystem repair
systemctl set-default
Changes the default target for next boot
Does not affect current system state
Writes to /etc/systemd/system/default.target
systemctl isolate
Changes current system state immediately
Starts target and stops all others
Does not change default for next boot
runlevel 0 (poweroff)
Halts the system
Maps to poweroff.target in systemd
Equivalent to 'systemctl poweroff'
runlevel 6 (reboot)
Reboots the system
Maps to reboot.target in systemd
Equivalent to 'systemctl reboot'
Mistake
runlevels are still the primary way to control system states in all modern Linux distributions
Correct
Most modern distributions use systemd targets instead of runlevels, though compatibility mappings exist. Runlevels are legacy from SysV init.
Beginners often learn from older tutorials or books that focus on 'init' and 'runlevels' and don't realise systemd has replaced them in Ubuntu, Fedora, Debian, Arch, etc.
Mistake
changing the default target with 'systemctl set-default' immediately changes the current running state
Correct
systemctl set-default only changes what target is used on next boot. To change the current state, you must use 'systemctl isolate'.
The word 'set-default' sounds permanent and immediate, leading beginners to think it applies now. The actual command 'systemctl isolate' is less intuitive.
Mistake
rescue.target and emergency.target are the same thing
Correct
rescue.target mounts the root filesystem read-write and starts some basic services; emergency.target mounts root read-only and gives a minimal shell without even bringing up the network.
Both are used for recovery, so it's natural to assume they are identical. The subtle difference is critical for LPIC-1, especially when the exam asks which target to use when filesystem repair is needed.
Mistake
runlevel 3 always maps to multi-user.target and runlevel 5 always maps to graphical.target in all distributions
Correct
The mapping is consistent for poweroff.target (0) and reboot.target (6), but runlevels 2-5 can be configured differently. Debian-based systems often have runlevels 2-5 all defaulting to multi-user.target, while Red Hat uses runlevel 5 for graphical.target.
The exam tests generic mapping, but different distributions handle runlevels differently. Beginners assume one-size-fits-all, but they must know the default convention.
Mistake
you cannot change the default boot target without using systemctl
Correct
You can manually edit the symbolic link at /etc/systemd/system/default.target to point to a different target file, for example: 'ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target'.
Beginners often think systemctl is the only way, but LPIC-1 tests understanding of underlying files. The exam may present a scenario where systemctl isn't available (e.g., minimal recovery).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Runlevels are numeric states (0-6) used by the old SysV init system. Systemd targets are named units (e.g., multi-user.target) that are more flexible and can have dependencies. Modern Linux uses targets, but runlevels still map to targets for compatibility.
Run 'sudo systemctl set-default multi-user.target' to make the system boot into text mode. Reboot to see the change. To revert, use 'sudo systemctl set-default graphical.target'.
The command 'systemctl get-default' displays the default target that will be used on next boot. It reads the symbolic link at /etc/systemd/system/default.target.
Yes, by editing the GRUB boot parameters and adding 'systemd.unit=rescue.target' (or 'single' for older SysV). This drops you into a shell as root, but if the system has a root password set, some versions may require it. For full access, you may need to break the root password or use a live CD.
rescue.target mounts the root filesystem read-write and starts essential services like networking. emergency.target mounts root read-only and provides only a minimal shell with no network. Use emergency.target when filesystems are corrupted; use rescue.target for general repair.
Use the 'runlevel' command. It shows the previous runlevel (or 'N' if none) and the current runlevel. On systemd, this is derived from the current target, so 'runlevel' might show '5' for graphical.target or '3' for multi-user.target.
You've finished Runlevels, Targets, and System Initialization. Continue through the LPIC-1 study guide to build a complete picture of the exam.
Done with this chapter?