There are times when Linux system boots either into a Graphical User Interface (GUI) or a command line. A Linux system may also boot as a single-user system, which means that it is available only to a single user, the superuser used for system maintenance.
The way the Linux system boots and operates is known as the system’s state, known as the runlevel.
Objectives
In this tutorial, we will learn about the various runlevels that exist within a Linux system.
Table of Contents
Prerequisites
- Access to a Linux machine. In this tutorial we’ll use an Ubuntu Virtual Machine with a GUI.
- Acting as a non-root sudo user to ensure a secure environment
Runlevel Overview
When we boot a Linux system, it boots with the predefined conditions, which define its state. For example, we may boot a Linux system, such as Ubuntu, into a command line and work from there. This is typically done by expert Linux users. On the other hand, we may want to boot into the GUI. These are different states, which we call runlevels.
There are two key reasons for defining a runlevel in a Linux system:
- Defines the programs or applications that need to execute when the system boots
- Defines the state of the system when it boots, such as whether the GUI is available or not
Before we proceed further, we can quickly find the runlevel of the Ubuntu installation by using the following command:
runlevel
Notice that the output displays a number, which is 5 in this case. This is the default runlevel in most Linux distributions. We can, however, change it to a different runlevel.
N 5
Another method we can use to find the runlevel is by using the who command with the -r parameter:
who -r
We get two different runlevels here. We get the current runlevel along with another runlevel, which was the last runlevel. If we had ever changed the runlevel from the default, it would be listed with the last parameter in the output. In our scenario, the last runlevel was 3, and the current one is 5.
run-level 5 2021-08-06 18:54
We can also use the systemctl command, which we will look at later in this tutorial.
Before using any command, it is always advisable to read through the help to understand its parameters. We can get the help on runlevels by using the following command:
runlevel --h
Notice that the help also contains a reference to the man pages. We should be able to get more details on the runlevels.
runlevel [OPTIONS...] Prints the previous and current runlevel of the init system. Options: --help Show this help See the runlevel(8) man page for details.
Let’s quickly see what the man pages hold by executing the following command:
man runlevel
The man pages display a total of 7 runlevels, which range from 0 to 6. Each runlevel is designated to perform a specific task.
RUNLEVEL(8) runlevel RUNLEVEL(8) NAME runlevel - Print previous and current SysV runlevel SYNOPSIS runlevel [options...] OVERVIEW "Runlevels" are an obsolete way to start and stop groups of services used in SysV init. systemd provides a compatibility layer that maps runlevels to targets, and associated binaries like runlevel. Nevertheless, only one runlevel can be "active" at a given time, while systemd can activate multiple targets concurrently, so the mapping to runlevels is confusing and only approximate. Runlevels should not be used in new code, and are mostly useful as a shorthand way to refer the matching systemd targets in kernel boot parameters. Table 1. Mapping between runlevels and systemd targets ┌─────────┬───────────────────┐ │Runlevel │ Target │ ├─────────┼───────────────────┤ │0 │ poweroff.target │ ├─────────┼───────────────────┤ │1 │ rescue.target │ ├─────────┼───────────────────┤ │2, 3, 4 │ multi-user.target │ ├─────────┼───────────────────┤ │5 │ graphical.target │ ├─────────┼───────────────────┤ │6 │ reboot.target │ └─────────┴───────────────────┘ ...
So, what does this mean, let’s proceed further to understand the numbers used to define the runlevels. The man pages displayed a total of 7 runlevels, which are:
Run Level | Targets | Description |
0 | poweroff.target | Shuts down the Linux system |
1 | rescue.target | Runs a single user mode and is used by the superuser, which is the root. Non-root logins are disallowed for login. No daemons are started. |
2 | Runs in the multi-user mode but does not start the daemons or network interfaces | |
3 | multi-user.target | Runs the system in the multi-user mode but without a graphical user interface. Only a command-line interface is used |
4 | Is undefined, which can be defined by a user. This runlevel is typically not used. | |
5 | graphical.target | Runs the system in the multi-user mode but with a graphical user interface. This runlevel is used by most Linux systems. |
6 | reboot.target | Reboots the system as soon as the runlevel command is executed. |
Location for Runlevel Files
Now that we know what runlevels are, we must understand that each runlevel is a specific environment executed through a specific set of scripts. So, where are these scripts stored? Let’s find that out.
In a Linux system, we have the /etc directory, which contains the system-wide configuration files. The /etc directory contains several subdirectories as well as configuration files. The runlevel files are stored in their respective directories, which are named as:
- rc0.d
- rc1.d
- rc2.d
- rc3.d
- rc4.d
- rc5.d
- rc6.d
Each of the subdirectories is designed to keep the configuration files for a specific runlevel. Let’s first view these subdirectories by executing the following command:
ls /etc
The output of the ls command is now listed. We need to scroll back up to view the rc set of subdirectories.
cpi hdparm.conf pnm2ppa.conf adduser.conf host.conf polkit-1 alsa hostid popularity-contest.conf alternatives hostname ppp anacrontab hosts profile apg.conf hosts.allow profile.d apm hosts.deny protocols apparmor hp pulse apparmor.d ifplugd python2.7 apport ImageMagick-6 python3 appstream.conf init python3.8 apt init.d rc0.d avahi initramfs-tools rc1.d bash.bashrc inputrc rc2.d bash_completion insserv.conf.d rc3.d bash_completion.d iproute2 rc4.d bindresvport.blacklist issue rc5.d binfmt.d issue.net rc6.d bluetooth kernel rcS.d brlapi.key kernel-img.conf resolv.conf brltty kerneloops.conf rmt brltty.conf ldap rpc ...
Let’s view the files in /etc/rc0.d
subdirectory, which is used for runlevel 0:
ls /etc/rc0.d/
The output of the ls command is now listed. A set of configuration scripts and files are stored in this subdirectory.
K01alsa-utils K01kerneloops K01saned K01avahi-daemon K01open-vm-tools K01speech-dispatcher K01bluetooth K01openvpn K01spice-vdagent K01cups-browsed K01plymouth K01udev K01gdm3 K01pulseaudio-enable-autospawn K01unattended-upgrades K01irqbalance K01rsyslog K01uuidd
Changing Runlevel
Just as a quick recap, we now know what a runlevel is, along with the directory and subdirectory where its configuration files are stored. We need to now move ahead and change the runlevel.
There are two ways to change a runlevel. The first method is to change it using the init or telinit commands. We will first use the init command:
init 6
This command reboots the system. We get the same output if we execute the telinit command:
telinit 6
Let’s now look at the systemctl command that helps us find the current runlevel and helps us change it as well. Let’s execute this command to first find the runlevel:
systemctl get-default
Notice that the output displays a graphical.target, which is the runlevel 5, as seen in the table above.
graphical.target
Now, it is time to change the runlevel using the systemctl command. To do this, execute the following command:
sudo systemctl isolate multi-user.target
The moment we press Enter, we are taken to the command line to provide the user credentials. After successful authentication, we are now on the command line.
Let’s check the runlevel once again. We will simply use the runlevel
command:
runlevel
Notice that two runlevels are displayed. The first one, which is 5, is the last runlevel that was used. The next number, which is 3, is the current runlevel.
Let’s get back to the GUI using the following command:
sudo systemctl isolate graphical.target
We are prompted for authentication for the user edxd because we are using sudo. After successful authentication, the system boots into the GUI environment, where we need to select the appropriate user and log on to the system. After successful authentication, we are back on the GUI mode.
Conclusion
Well done. Hopefully, this tutorial helped us understand the Linux runlevels. If you encountered any issues, or have any questions, please feel free to leave a comment or contact us, and we’ll get back to we as soon as we can.
Thank you! ?
Sysmed will change all this. Witch will make this post a moot point .