What Does Runlevel Mean?
This page mentions older exam versions. See the Current Exam Context and Legacy Exam Context sections below for the updated mapping.
On This Page
Quick Definition
A runlevel is a setting that tells your computer which programs and services to start when it boots up. Think of it like a mode switch for your operating system. Different runlevels are used for different tasks, like normal operation, maintenance, or shutting down. It helps the system know what it should be doing at any given time.
Commonly Confused With
A runlevel is the operational state of the entire system. A process state (like running, sleeping, zombie) is the current activity of a single program. They are completely different levels of abstraction.
The system can be in runlevel 3 (multi-user), while a specific process like a web server is in a 'running' state.
The kernel also has operational modes, like user mode and kernel mode for CPU privilege levels. This is unrelated to SysV runlevels. SysV runlevels control which userspace services run, not the kernel's execution mode.
The kernel switches between user mode and kernel mode millions of times per second to handle system calls. A runlevel change happens only when an administrator explicitly requests it.
In modern systemd-based systems, 'targets' replace runlevels. While they serve the same purpose (defining the system state), the commands and configuration files are different. For example, 'multi-user.target' is the equivalent of runlevel 3, but you use 'systemctl' instead of 'telinit'.
To switch to rescue mode (like runlevel 1) on systemd, you use 'systemctl rescue', not 'telinit 1'.
Must Know for Exams
Runlevels are a specific objective in several major IT certification exams, particularly those focused on Linux system administration. For the CompTIA Linux+ (XK0-005), runlevels fall under Domain 1: System Management. Candidates must know how to change runlevels, identify the current runlevel, and understand the purpose of standard runlevels. Questions often involve booting into single-user mode (runlevel 1) for password recovery or system repair. The exam may present a scenario where a service fails to start, and the candidate must determine which runlevel to enter for troubleshooting.
For the LPIC-1 (101-500 and 102-500) exams, runlevels are explicitly listed in Topic 102: Linux Installation and Package Management, and Topic 103: GNU and Unix Commands. Specifically, objective 103.7 covers searching, extracting, and manipulating text, but more importantly, objective 101.3 covers runlevels and the boot process. This includes knowing the init not runlevel directories, using telinit to switch runlevels, and the 'runlevel' command. Exam questions may ask which runlevel is used for single-user mode, or what command to use to shut down the system to runlevel 0.
Questions can be of several types. There are straightforward knowledge-based questions, like 'Which runlevel is associated with a full reboot?' The answer is 6. There are scenario-based questions, like 'A system administrator needs to perform maintenance on a production file system that cannot be unmounted while in use. Which runlevel should they switch to?' The answer is 1 (single-user mode). There are also command-line recall questions, like 'What command can be used to change the runlevel to 3 without rebooting?' The answer is 'telinit 3' or 'init 3'. Another common question format involves the contents of configuration files, such as /etc/inittab, which defines the default runlevel. Although systemd is now dominant, many legacy questions still reference SysV init, and the LPIC-1 exam still covers it. Understanding runlevels thoroughly is a low-effort, high-return area for exam preparation.
Simple Meaning
Imagine your computer is like a car. When you turn the key, the car can be in different modes. Park is like the system being completely off, just waiting. Reverse is like a special maintenance mode where only essential systems are running, maybe for repairs. Drive is the normal mode where everything is on and ready to go. Runlevels work the same way. They are pre-defined states that your Linux or Unix system can be in. Each state has a specific purpose and a specific set of services that are either turned on or off.
For example, runlevel 1 is often called single-user mode. This is a stripped-down state where only the most basic system functions are active, and you are the only user. It is used for administrative tasks like fixing a broken system or resetting a password. Runlevel 3 is typically the standard multi-user mode for servers. It starts all the normal services, like networking, web servers, and database services, but it does not start the graphical user interface (GUI). Runlevel 5 is like runlevel 3, but it also starts the graphical desktop, so you see a login screen with windows and icons.
There are also runlevels for shutting down or rebooting the system. Runlevel 0 is used to halt the system, turning off all services and powering down the computer. Runlevel 6 is used to reboot, which briefly runs services to safely restart the machine. By switching between these runlevels, the system administrator can control what the computer does without manually starting and stopping every single program. It is an old but powerful way to manage a system's operational state, especially on servers that run for months or years without a full restart.
Full Technical Definition
In Unix and Unix-like operating systems, particularly those using System V init (SysV init), a runlevel is a digit or letter that defines a specific operational state of the machine. The init process, which is the first process started by the kernel (PID 1), is responsible for transitioning the system between runlevels. Each runlevel corresponds to a set of services that should be running, defined by symbolic links in directories under /etc/rc.d/ or /etc/init.d/, typically named rc0.d through rc6.d. When entering a runlevel, the init process first runs scripts in the rcX.d directory to stop services not needed in the new runlevel, and then runs scripts to start services that are required. The scripts themselves are usually shell scripts that manage daemons.
Standard runlevels are defined as follows: runlevel 0 (halt or shutdown), runlevel 1 (single-user mode, usually for maintenance), runlevel 2 (multi-user mode without network services), runlevel 3 (multi-user mode with network services, but no GUI), runlevel 4 (user-definable, often unused), runlevel 5 (multi-user mode with GUI), and runlevel 6 (reboot). These are not universal, however, as different Unix flavors and Linux distributions have historically used slightly different conventions. For example, Slackware Linux uses runlevels 1 through 4 for different console modes, and runlevel 5 for X11.
Modern Linux distributions have largely moved away from SysV init in favor of systemd, which uses targets instead of runlevels. However, systemd maintains backward compatibility by mapping traditional runlevels to specific targets. For instance, runlevel 3 maps to multi-user.target, and runlevel 5 maps to graphical.target. The command 'runlevel' displays the previous and current runlevel. The 'telinit' or 'init' command can be used to change runlevels on the fly, such as 'telinit 1' to enter single-user mode. Understanding runlevels is crucial for system recovery, as booting into a specific runlevel (e.g., via the kernel command line in GRUB) can bypass malfunctioning services, allowing an administrator to repair the system. The concept is also deeply tied to the concept of system states and service dependencies, a foundational idea in system administration.
Real-Life Example
Think of a large office building. The building has different modes of operation depending on the time of day and who is there. At night, when everyone is gone, the building is in 'Night Mode' (like runlevel 0). The main power is off, only emergency lights are on, and the security system is armed. No work can be done. In the early morning, a janitor arrives. The building switches to 'Cleaning Mode' (like runlevel 1). The main lights in the hallways come on, the cleaning equipment is powered up, but the office computers and air conditioning are still off. Only one person is in the building, and they have limited access.
Then, during regular business hours, the building is in 'Normal Office Mode' (like runlevel 3). The elevators are running, all the lights are on, the HVAC system is regulating temperature, the network is active, printers are available, and employees can use the internet and their desktop computers. Everything is operational, but there is no music playing or special events. This is the standard productive state.
On a special day, like a company-wide celebration, the building might switch to 'Event Mode' (like runlevel 5). In addition to everything in Normal Office Mode, the audio system is playing music, the projector in the conference room is on, and the catering service is active. This is a more feature-rich state. Finally, at the end of the day, the building manager can switch to 'Shutdown Mode' (like runlevel 6), which temporarily powers up the backup generators, runs a quick safety check, and then gracefully powers everything down before turning off the main power. The building transitions between these modes smoothly, each mode having a specific set of allowed activities and enabled systems, just like runlevels in a computer server.
Why This Term Matters
In practical IT, runlevels matter because they provide a structured, scriptable way to control the system state without manual intervention. For a system administrator managing hundreds or thousands of Linux servers, the ability to change the system's operational mode with a single command is critical. For example, if a server has a faulty display driver that causes the entire system to crash when the GUI starts, an administrator can instruct the boot loader to boot into runlevel 3 (multi-user without GUI). This allows them to log in, fix the driver, and then switch back to runlevel 5. Without runlevels, they would need a physical console or a complex rescue procedure.
Runlevels are also essential for scripting automated tasks. A script can safely change the runlevel to 1 for maintenance, perform disk checks or software updates, and then return the system to runlevel 3 or 5. This is far more reliable than manually killing and starting services. Understanding runlevels is key to troubleshooting boot problems. If a system hangs during boot, knowing which runlevel it is trying to reach and which services start in that runlevel helps isolate the failing service.
In many IT certification exams, such as the CompTIA Linux+ and LPIC-1, runlevels are a standard topic. They represent a core concept of system management. Even though modern systemd has replaced init, the concept of operational targets is directly derived from runlevels. A professional who understands runlevels will grasp systemd targets, boot processes, and service management much more easily. It is a foundational building block for understanding how a Unix-like system operates from power-on to full operation, and how to gracefully handle transitions between different operational states.
How It Appears in Exam Questions
Exam questions about runlevels typically appear in three main patterns: direct definition, scenario-based troubleshooting, and command-line configuration. A direct definition question might ask, 'What is the primary purpose of runlevel 1 on a Linux system?' The answer is 'Single-user mode for maintenance and repair.' Another example: 'Which runlevel is typically runlevel 6?' Answer: 'Reboot.' These require simple memorization.
Scenario-based questions are more common. For example: 'A Linux server is experiencing a kernel panic on boot. The administrator needs to bypass the startup scripts that may be causing the issue. How can they enter a minimal environment to diagnose the problem?' The correct answer is to interrupt the boot process (e.g., by pressing 'e' in GRUB) and append '1' or 'single' to the kernel line to boot into runlevel 1. Another scenario: 'A technician needs to install a critical security patch that requires all non-essential services to be stopped. What is the most appropriate runlevel to use for this maintenance window?' The answer would be runlevel 1 or runlevel S (single user).
Command-line questions might ask: 'Given the current runlevel is 5, which command will change the system to runlevel 3 without rebooting?' The correct command is 'telinit 3' or 'init 3'. A variation might ask: 'After running 'runlevel' the output is '5 3'. What does this indicate?' The interpretation is that the previous runlevel was 5, and the current runlevel is 3 (the system has just transitioned from graphical to multi-user text mode). There are also configuration questions: 'In the /etc/inittab file, which line sets the default runlevel? What is the default runlevel id for runlevel 5?' The line 'id:5:initdefault:' sets the default. This type of question is becoming less common as /etc/inittab is deprecated in many modern distros, but it still appears on exams like LPIC-1. Finally, questions may involve the concept of runlevels in the context of systemd, asking which target corresponds to runlevel 3 (multi-user.target) or runlevel 5 (graphical.target). Being able to map between SysV runlevels and systemd targets is a strong differentiator.
Study CompTIA Linux+
Test your understanding with exam-style practice questions.
Example Scenario
You are a junior system administrator for a small company that runs an internal web server on a Linux machine. The server is currently at runlevel 5, which means it is running the full graphical desktop environment. One day, you need to install a critical software update that requires restarting the web server service and some background daemons. However, you also need to perform a filesystem check on the /var partition, which is heavily used by the web server and cannot be unmounted while the server is running.
You cannot shut down the entire server because other employees might be working. You decide to switch to a maintenance mode. You log into the server via SSH. You know that runlevel 1 is single-user mode, where only essential system processes run and the network is typically disabled. But since you are connected via SSH, disabling networking would disconnect you. So you first plan to perform the filesystem check locally or use a virtual console. You switch to runlevel 1 using the command 'telinit 1'. The system immediately stops most services, including the web server and the network. You then run the filesystem check on /var. After the check completes, you run the software update. With the update complete, you need to bring the server back to its full operational state. You switch back to the default runlevel by typing 'telinit 5'. The system starts all the normal services, including the web server, and within minutes, the server is fully operational again. The entire process required only two commands and a few minutes of downtime, rather than a full reboot which would have required coordinating with users. This is a classic example of using runlevels for system administration tasks without a full system restart.
Common Mistakes
Thinking runlevel 0 is the same as runlevel 6.
Runlevel 0 halts the system completely, turning off power. Runlevel 6 reboots the system. They are different actions.
Memorize: 0 = halt (power off), 6 = reboot (restart).
Using 'init 1' on a production system without understanding that it stops all services, including networking.
Runlevel 1 typically disables networking, which will terminate your remote SSH session. This can leave you locked out of the server if you don't have physical or out-of-band access.
Before switching to runlevel 1 remotely, ensure you have a local console or a management card (like IPMI) to regain access. Alternatively, use 'init S' which is sometimes slightly different but similar.
Confusing runlevels with process states (like in 'ps' command output).
A runlevel is the overall system state. Process states (like R, S, D, Z in ps output) indicate what an individual process is doing at a given moment. They are unrelated concepts.
Remember runlevels apply to the whole machine; process states are per-program.
Assuming runlevel numbers are universal across all Unix-like systems.
While the SysV convention is standard, customizations exist. For example, some systems use runlevel 2 as multi-user with network, while others use it for single-user. Always check the specific distribution's documentation.
When working on a new system, check /etc/inittab or the systemd target mapping to confirm the runlevel definitions.
Forgetting that systemd targets are the modern equivalent, not runlevels themselves.
Many modern Linux distributions use systemd, which does not use /etc/inittab or runlevels directly. Using 'init 3' on a systemd system will often work via compatibility, but the preferred method is 'systemctl isolate multi-user.target'.
On systemd systems, use 'systemctl get-default' and 'systemctl isolate' for runlevel-like control.
Exam Trap — Don't Get Fooled
{"trap":"The exam asks: 'Which runlevel should you use to perform a full system backup of a server that has the most services running?' A learner might choose runlevel 1.","why_learners_choose_it":"They think runlevel 1 is for maintenance, and backups are maintenance.
However, runlevel 1 stops most services, including the network and possibly the backup service itself.","how_to_avoid_it":"For a full online backup, you usually want the system in its normal operation mode (runlevel 3 or 5) so that all your backup targets (databases, file shares) are available. Runlevel 1 is for repairs, not for running backup jobs.
The correct answer is to stay in the current runlevel (usually 3) and use a backup tool that can handle live data."
Step-by-Step Breakdown
System Power-On
When a computer is powered on, the BIOS or UEFI performs a POST (Power-On Self-Test) and then loads the bootloader from the disk. The bootloader (like GRUB) then loads the kernel into memory.
Kernel Initialization
The kernel initializes hardware, mounts the root filesystem, and then starts the init process (PID 1). The init system (whether SysV init or systemd) is responsible for bringing the system to its default runlevel.
Reading the Default Runlevel
In SysV init, the init process reads the /etc/inittab file to find the 'initdefault' entry, which specifies the default runlevel (e.g., 'id:3:initdefault:'). In systemd, this is mirrored by the default target (e.g., 'multi-user.target').
Changing to the Default Runlevel
The init process runs the scripts in the corresponding rc.d directory. For runlevel 3, it executes scripts in /etc/rc.d/rc3.d/. Scripts starting with 'K' (kill) stop services, and scripts starting with 'S' (start) begin services. They run in alphabetical order.
Service Script Execution
Each script in the rc directory is a symbolic link to a script in /etc/init.d/. The script tasks with a parameter 'start' or 'stop'. For example, S55sshd would start the SSH daemon. This step transitions the system to the target runlevel.
System Ready
Once all necessary services are started, the system is in the target runlevel. For runlevel 3, the system is ready for multi-user console logins. For runlevel 5, the graphical display manager (like GDM or LightDM) is started, presenting a graphical login screen.
Runlevel Change (Runtime)
An administrator can change the runlevel at any time using 'telinit [new_runlevel]'. The init process then reads the rc.d directory for the new runlevel, stops services that should not be running (using K scripts), and starts services that should be running (using S scripts). This is a dynamic state transition.
Practical Mini-Lesson
Understanding runlevels is pivotal for real-world Linux system administration, even though modern tools have evolved. The core skill is knowing how to control the system state safely. In practice, the most common use cases are booting into single-user mode for emergency repairs and switching between multi-user and graphical modes. When a system fails to boot normally, the administrator will often see a message like 'Reached target Graphical Interface' or 'Starting Network Manager.' If the boot hangs at one of these steps, knowing which runlevel or target is failing helps diagnose the problem.
To enter single-user mode during boot on a SysV system, you can add a number (e.g., '1' or 'single') to the kernel command line at the GRUB prompt. This tells init to start at that runlevel immediately. In single-user mode, the root filesystem is usually mounted read-only. You must remount it as read-write using 'mount -o remount,rw /' to make changes. This is a classic recovery step.
For day-to-day administration, you might run a script that changes runlevels. For example, a script that performs a backup might first switch to runlevel 1 to ensure no data is being written, perform the backup, and then switch back to runlevel 3. However, this is risky because it stops all services. A better practice is to use more granular service management, such as 'systemctl stop [service]' or 'service [service] stop' in SysV. Runlevel switching is often too blunt an instrument for modern, service-oriented environments.
What can go wrong? A common mistake is to forget that changing runlevels kills processes. If a developer is running a critical batch job on a server, and an administrator switches to runlevel 1, that job is killed abruptly. This can lead to data corruption. Therefore, always communicate with users before a runlevel change. Another issue is that some services may not gracefully stop in certain runlevels, leading to hung processes or filesystem locks. In such cases, you may need to force kill processes (using 'kill -9') or perform a more aggressive shutdown. Understanding these risks is what separates a competent administrator from a novice. On modern systemd systems, 'systemctl isolate multi-user.target' can be used to achieve a similar result, but with more granular control over dependencies via 'Requires' and 'Wants' directives.
Finally, configuration files for custom runlevels are rarely used today but can be found on legacy systems. If you see /etc/inittab, respect it. Never edit it without a backup, and always run 'telinit q' to reload the configuration if you do. For exam purposes, be ready to interpret the contents of /etc/inittab, even if it is old-fashioned.
Memory Tip
Use the mnemonic '0 Halt, 1 Single, 2 Multi no net, 3 Multi with net, 4 Custom, 5 GUI, 6 Reboot' to remember the standard runlevels.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
XK0-006CompTIA Linux+ →Legacy Exam Context
Older materials may mention these exam versions, but learners should use the current objectives for their target exam.
XK0-005XK0-006(current version)Related Glossary Terms
A 2-in-1 laptop is a portable computer that can switch between a traditional laptop form and a tablet form, usually by detaching or rotating the keyboard.
The 24-pin motherboard connector is the main power cable that connects the computer's power supply unit (PSU) to the motherboard, supplying electricity to the motherboard and its components.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
A 3D printer is a device that creates physical objects by depositing layers of material based on a digital model.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
The 8-pin CPU connector is a power cable from the power supply that delivers dedicated electricity to the processor on a computer's motherboard.
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Frequently Asked Questions
What is the difference between runlevel 0 and runlevel 6?
Runlevel 0 halts (powers off) the system, while runlevel 6 reboots the system. Both are used to stop operation, but one turns the system off and the other restarts it.
Can I create my own runlevel?
Yes, runlevel 4 is typically user-definable. You can create custom scripts in the /etc/rc.d/rc4.d/ directory to define your own state. However, this is rarely done today because systemd targets offer more flexible customization.
How do I check the current runlevel?
Use the command 'runlevel' in the terminal. It will output the previous and current runlevel, for example 'N 3' (N means no previous runlevel, current is 3). On systemd, use 'systemctl get-default' for the default target.
What happens if I set the default runlevel to 0 or 6?
If you set the default runlevel to 0, the system will immediately shut down upon booting. If set to 6, it will continuously reboot. This is a common configuration mistake that can render a system unbootable without a repair procedure.
Is runlevel used only for booting?
No, runlevels can be changed at any time while the system is running using the 'telinit' or 'init' command. This allows for dynamic changes between operational states without a full restart.
How does runlevel relate to systemd's 'multi-user.target'?
They are functionally equivalent. Runlevel 3 maps to 'multi-user.target' in systemd. When you use 'systemctl isolate multi-user.target', you are achieving the same effect as 'telinit 3' on a SysV system.
Summary
Runlevels are a foundational concept in Unix-like system administration, representing the operational state of the entire operating system. From runlevel 0 (shutdown) to runlevel 6 (reboot), each state defines a specific set of services that are active, allowing administrators to control the system's behavior. The most critical runlevel for practical administration is runlevel 1 (single-user mode), which provides a minimal environment for performing repairs, recovering passwords, or fixing filesystem issues.
While modern systems have largely transitioned to systemd targets, the concept of runlevels remains essential knowledge for IT certification exams like CompTIA Linux+ and LPIC-1. Understanding the mapping between old SysV runlevels and new systemd targets is a key skill. In exams, expect direct definition questions, scenario-based troubleshooting, and command-line recall questions.
The most common mistakes include confusing runlevels with process states, forgetting that runlevel 1 disables networking, and assuming runlevel numbers are universal. The key takeaway for any IT professional is that runlevels are a powerful tool for managing system state safely and efficiently, and mastering them demonstrates a solid grasp of system management fundamentals.