Managing Runlevels

What Is a Runlevel?
So what exactly is a runlevel? It sounds complicated, but when you get right down to it, it really isn’t. A runlevel represents one of several different modes that your Linux system can run in. A runlevel on a Linux system is similar, in many ways, to a startup mode on a Windows system. If you’ve used Windows, you know that you can press the f8 key during system boot and select one of several startup modes. For example, if you’re having trouble with a particular device or driver in your Windows system, you can boot it in Safe Mode, which will load the operating system with only a minimal set of drivers so that you can troubleshoot the problem.
Linux runlevels are similar. Like Windows startup modes, Linux runlevels allow you to specify the mode in which you want your system to run. Linux uses seven default runlevels that you can choose from, as shown in Table 6-3. 

Defining Runlevels with /etc/inittab

For distributions that use init, the init process is the grandparent of all other processes on your Linux system. It is the first process run by the kernel at boot and is responsible for loading all other system processes that make Linux work. The init process is configured in the /etc/inittab file. An excerpt from a typical inittab file for an openSUSE system follows:

fs2:~ # cat /etc/inittab

# /etc/inittab

id:5:initdefault:

# First script to be executed, if not booting in emergency (-b) mode

si::bootwait:/etc/init.d/boot

l0:0:wait:/etc/init.d/rc 0

l1:1:wait:/etc/init.d/rc 1

si::bootwait:/etc/init.d/boot

The bootwait parameter tells init to run this script and to wait for it to complete before

proceeding with the boot process.

In addition, the inittab file also defines what init scripts are run in each runlevel. This is done using the following lines:

l0:0:wait:/etc/init.d/rc 0

l1:1:wait:/etc/init.d/rc 1

l2:2:wait:/etc/init.d/rc 2

The syntax for commands within the inittab file is 

identifier:runlevel:action:command.

 The wait action specified in these commands tells the init process to wait until the scripts for the specified runlevel have finished running before moving on. Also, notice that the definition for runlevel 4 is commented out. Runlevel 4 is left undefined by default in every Linux distribution

I’ve ever used.

The /etc/inittab file also defines what should happen when the ctrl-alt-del key combination is pressed. By default, the inittab file causes the system to restart when these keys are pressed, as shown here:

ca::ctrlaltdel:/sbin/shutdown -r -t 4 now

Notice in the inittab example that a single-user mode is also defined (S): 

# what to do in single-user mode

ls:S:wait:/etc/init.d/rc S

~~:S:respawn:/sbin/sulogin

The single-user mode is very useful when troubleshooting system problems. When you enter single-user mode, the /sbin/sulogin command is run, allowing you to log in as root and fix whatever problem is keeping the system from running correctly. To enter single-user mode while the system is running, enter init S at the shell prompt. When you do, you’re prompted to provide your root user password. Once this is entered, you are granted root access to the system in single-user mode. 

About init Scripts 

The system processes on your Linux system are started and stopped using an init script. An init script is used by the init process to start processes on system boot and whenever the current runlevel is changed. These scripts are stored in a specific directory on your Linux system. Which directory they are stored in depends on your Linux distribution. Most Linux distributions use one of two types of init scripts: 

• System V Linux distributions that use System V init scripts store them in the /etc/ rc.d directory. Within /etc/rc.d are a series of subdirectories named rc0.d through rc6.d. Each of these directories is associated with a particular runlevel. Within each of these subdirectories are symbolic links that point to the init scripts for your system daemons, which reside in /etc/rc.d/init.d.

• BSD Linux distributions that use BSD-style init scripts store them in the /etc/init.d directory. Within /etc/init.d are a series of directories named rc0.d through rc6.d. As with System V init scripts, these directories are associated with a specific runlevel. These directories contain links that point to the init scripts in /etc/init.d.
In addition to using the init process to run these scripts, you can run these scripts from the command prompt. Simply enter /etc/init.d/script_name at the shell prompt (on a BSD-style system) or /etc/rc.d/init.d/script_name (on a System V–style system). If you’re not sure of which script name you should use, you can use the ls command to generate a listing of scripts in the init script directory. 

The actual scripts in your init directory depend on which services you’ve installed on your particular system. Whenever you use the rpm utility to install a service on your system, a corresponding init script is automatically installed in your init script directory. Once there, you can execute any script by simply running it from the command prompt. The syntax on a BSD-style system is as follows: 

/etc/init.d/script_name start | stop | restart

You can use the following parameters when running init scripts: 

• start: Use this parameter to start the associated service. 

• • stop: Use this parameter to stop the associated service.  

• status: Use this parameter to view the status of the service, such as whether it is currently running

• restart : Use this parameter to stop and then start the associated service. This is a very useful option if you’ve made extensive configuration changes to the service and it needs to be restarted to apply the changes.

• reload:  Use this parameter to reread the service’s configuration file without restarting the service itself. Not all daemons support this option. 

For example, to run the smb service, you would enter /etc/init.d/smb start at the shell prompt. To stop it, you would enter

/etc/init.d/smb stop. To restart it, you would enter /etc/init.d/smb restart.

On some distributions, such as SUSE Linux, you can also use the rc script to start, stop, or restart a service process without having to specify the full path to the script file. The syntax is rcscript_name start | stop | restart. For example, to start the smb service, you could enter rcsmb start at the shell prompt. To stop it, you could enter rcsmb stop. You could also use the restart option to restart it. 

Configuring the Default System Runlevel 

As you saw earlier in this chapter, the system’s default runlevel is specified in the /etc/inittab file. You can change the default runlevel by simply changing the second value in the command to the runlevel you want to use. For example, suppose I wanted to change my system from the default runlevel of 5 to 3. I would simply open /etc/inittab in a text editor and change the value 5 to 3. After I save the file and reboot, the system would boot into runlevel 3. 

In addition to changing runlevels at boot time, you can also change them on the fly as you’re using the system. Let’s discuss how this is done next. 

Changing Runlevels from the Shell Prompt 

If you think changing the default runlevel is easy, changing runlevels on the fly is even easier. This is done with the init command. The syntax for using init is init runlevel. For example, if my system is running in runlevel 5 and I want to switch to runlevel 3, I can simply enter init 3 

If you look inside an rcx.d directory within your distribution’s init directory, you will see two scripts for each system process. One starts with an S, and one starts with a K. The scripts that start with S are used to start a process, whereas the scripts that start with K are used to stop (kill) a process. When the init process calls rc and sends it a runlevel to change to, the rc process runs all the scripts in the corresponding rcx.d directory to start and stop services as appropriate for the runlevel being entered. These are the scripts employed when switching between runlevels on the fly as just described. 

Even though we call these files “scripts,” they aren’t. They are actually symbolic links that point to the real script files in your init script directory. This makes updating your Linux system much easier. If individual init scripts were maintained in each rcx.d directory and an update needed to be applied to a particular service, each init script in each rcx.d directory would have to be individually updated. What a lot of work! The chance of errors and inconsistency would be huge! 

Instead, because all the files in the various rcx.d directories are just symbolic links to the one copy of the service’s init script in the init directory, any updates that need to be applied can be made to only the one file. 

A sampling of the scripts in the rc5.d directory is shown in Figure 6-14. The S files call their associated init script with the start parameter, whereas the K files call their associated init script with the stop parameter. 

Also notice in Figure 6-14 that the letter K or S is followed by a number and then the name of the init script. The number in the filename is very important. When init calls the rc script to switch runlevels, the rc script first looks at the rcx.d directory for the current runlevel and  compares it with the rcx.d directory for the runlevel it is going to switch the system to. If there is a kill script for the service in the rcx.d directory for the current runlevel and a start script for the same service in the rcx.d directory for the new runlevel, the rc script leaves the service running because it should be running in both runlevels. 

If, on the other hand, there is a kill script for the service in the rcx.d directory for the current runlevel but there is no start script for the same service in the rcx.d directory for the new runlevel, the rc script runs the kill script to stop the service. Conversely, if there is a start script for the service in the rcx.d directory for the new runlevel and there is no start script for the same service in the rcx.d directory for the current runlevel, the rc script runs the start script to start the service. 

The number in the kill or start script filename comes into play at this point. This number determines the sequence in which the scripts are run. This ensures that services that other services are dependent on are started first. For example, a script assigned a number of 01 will be run before a script assigned a number of 02. This means a file in rc5.d named S02network is run after S01dbus but before S03syslog.