Linux, 101: Runlevels, shutdown, and reboot

Overview

In this article, learn to shut down or reboot your Linux system, warn users that the system is going down, and switch to single-user mode or a more or less restrictive runlevel. Learn to:

• Set the default runlevel

• Change between runlevels

• Change to single-user mode

• Shut down or reboot the system from the command line

• Alert users about major system events, including switching to another runlevel

• Terminate processes properly

Unless otherwise noted, the examples in this article use a Fedora 8 system with a 2.6.26 kernel. The upstart examples use Fedora 13 with a 2.6.34 kernel, or Ubuntu 10.10 with a 2.6.35 kernel. Your results on other systems may differ.

This article helps you prepare for Objective 101.3 in Topic 101 of the Linux Professional Institute's Junior Level Administration (LPIC-1) exam 101. The objective has a weight of 3.

Prerequisites

To get the most from the articles in this series, you should have a basic knowledge of Linux and a working Linux system on which to practice the commands covered in this article. Sometimes different versions of a program will format output differently, so your results may not always look exactly like the listings and figures shown here. In particular, the newer upstart system is changing many things that might be familiar to users of the traditional System V init process (see Init vs. Upstart for details). This article is directed specifically at the traditional System V init process, with only a very cursory overview of how upstart differs.

Runlevels

Runlevels define what tasks can be accomplished in the current state (or runlevel) of a Linux system. Every Linux system supports three basic runlevels, plus one or more runlevels for normal operation. The basic runlevels are shown in Table 1.

Beyond the basics, runlevel usage differs among distributions. One common usage set is shown in Table 2.

The Slackware distribution uses runlevel 4 instead of 5 for a full system running the X Window system. Debian and derivatives, such as Ubuntu, use a single runlevel for any multiuser mode, typically runlevel 2. Be sure to consult the documentation for your distribution.

Default runlevel

When a Linux system starts, the default runlevel is determined from the id: entry in /etc/inittab. Listing 1 illustrates a typical entry for a system such as Fedora 8 or openSUSE 11.2, both of which use runlevel 5 for the X Window System.

Edit this value if you want your system to start in a different runlevel, say runlevel 3.

Changing runlevels

There are several ways to change runlevels. To make a permanent change, you can edit /etc/inittab and change the default level as you just saw above.

If you only need to bring the system up in a different runlevel for one boot, you can do this. For example, suppose you just installed a new kernel and need to build some kernel modules after the system booted with the new kernel, but before you start the X Window System. You might want to bring up the system in runlevel 3 to accomplish this. You do this at boot time by editing the kernel line (GRUB) or adding a parameter after the selected system name (LILO). Use a single digit to specify the desired runlevel (3, in this case). We'll illustrate the process with a GRUB example. Suppose your /boot/grub/menu.lst file contains the stanza shown in Listing 2.

To bring this system up in runlevel 3, wait till the boot entries are displayed, select this entry and enter 'e' to edit the entry. Depending on your GRUB options, you may need to press a key to display the boot entries and also enter 'p' and a password to unlock editing. The GRUB screen on our Fedora 8 system looks like Figure 1.

After you enter telinit 5 you will see several messages flash by and your display will switch to the configured graphical login screen. Open a terminal window and verify that the runlevel has been changed as shown in Listing 4.

If you use the ls command to display a long listing of the telinit command, you will see that it really is a symbolic link to theinit command. We illustrate this in Listing 5

The init executable knows whether it was called as init or telinit and behaves accordingly. Since init runs as PID 1 at boot time, it is also smart enough to know when you subsequently invoke it using init rather than telinit. If you do, it will assume you want it to behave as if you had called telinit instead. For example, you may use init 5 instead of telinit 5to switch to runlevel 5.

Single-user mode

In contrast to personal computer operating systems such as DOS or Windows, Linux is inherently a multiuser system. However, there are times when that can be a problem, such as when you need to recover a major filesystem or database, or install and test some new hardware. Runlevel 1, or single-user mode, is your answer for these situations. The actual implementation varies by distribution, but you will usually start in a shell with only a minimal system. Usually there will be no networking and no (or very few) daemons running. On some systems, you must authenticate by logging in, but on others you go straight into a shell prompt as root. Single-user mode can be a lifesaver, but you can also destroy your system, so always be careful whenever you are running with root authority. Reboot to normal multiuser mode as soon as you are done.

As with switching to regular multiuser runlevels, you can also switch to single-user mode using telinit 1. As noted in Table 1, 's' and 'S' are aliases for runlevel 1, so you could, for example, use telinit s instead.

Clean shutdown

While you can use telinit or init to stop multiuser activity and switch to single-user mode, this can be rather abrupt and cause users to lose work and processes to terminate abnormally. The preferred method to shut down or reboot the system is to use the shutdown command, which first sends a warning message to all logged-in users and blocks any further logins. It then signals init to switch runlevels. The init process then sends all running processes a SIGTERM signal, giving them a chance to save data or otherwise properly terminate. After 5 seconds, or another delay if specified, init sends a SIGKILL signal to forcibly end each remaining process.

By default, shutdown switches to runlevel 1 (single-user mode). You may specify the -h option to halt the system, or the -roption to reboot. A standard message is issued in addition to any message you specify. The time may be specified as an absolute time in hh:mm format, or as a relative time, n, where n is the number of minutes until shutdown. For immediate shutdown, use now, which is equivalent to +0.

If you have issued a delayed shutdown and the time has not yet expired, you may cancel the shutdown by pressing Ctrl-c if the command is running in the foreground, or by issuing shutdown with the -c option to cancel a pending shutdown. Listing 6 shows several examples of the use of shutdown, along with ways to cancel the command.

You may have noticed that our last example did not cause a warning message to be sent. If the time till shutdown exceeds 15 minutes, then the message is not sent until 15 minutes before the event as shown in Listing 7. Listing 7 also shows the use of the -t option to increase the default delay between SIGTERM and SIGKILL signals from 5 seconds to 60 seconds.

If you do cancel a shutdown, you should use the wall command to send a warning to all users alerting them to the fact that the system is not going down.

As we said earlier, it is also possible to use telinit (or init) to shut down or reboot the system. As with other uses oftelinit, no warning is sent to users, and the command takes effect immediately, although there is still a delay between SIGTERM and SIGKILL signals. For additional options of telinit, init, and shutdown, consult the appropriate man pages.

Halt, reboot, and poweroff

You should know about a few more commands related to shutdown and reboot.

• The haltcommand halts the system.

• The poweroff command is a symbolic link to the halt command, which halts the system and then attempts to power it off.

• The rebootcommand is another symbolic link to the halt command, which halts the system and then reboots it.

If any of these are called when the system is not in runlevel 0 or 6, then the corresponding shutdown command will be invoked instead.

For additional options that you may use with these commands, as well as more detailed information on their operation, consult the man page.

/etc/inittab

By now, you may be wondering why pressing Ctrl-Alt-Delete on some systems causes a reboot, or how all this runlevel stuff is configured. Remember the id field in /etc/inittab? Well, there are several other fields in /etc/inittab, along with a set of init scripts in directories such as rc1.d or rc5.d, where the digit identifies the runlevel to which the scripts in that directory apply. Listing 8 shows the full inittab from our Fedora 8 system.

As usual, lines starting with # are comments. Other lines have several fields with the following format:

id:runlevels:action:process

id

is a unique identifier of one to four characters. Older versions limited this to two characters, so you will often see only two characters used.

runlevels

lists the runlevels for which the action for this id should be taken. If no runlevels are listed, do the action for all runlevels.

action

describes which of several possible actions should be taken

process

tells which process, if any, should be run when the action on this line is performed.

Some of the common actions that may be specified in /etc/inittab are shown in Table 3. See the man pages for inittab for other possibilities.

Listing 9 shows just the entry for Ctrl-Alt-Delete from Listing 8. So now you see why pressing Ctrl-Alt-Delete causes the system to be rebooted.

In this example, init will run the /etc/rc.d/rc script (or command) with the parameter of 5 whenever runlevel 5 is entered.init will wait until this command completes before doing anything else.

These scripts used by init when starting the system, changing runlevels, or shutting down are typically stored in the /etc/init.d or /etc/rc.d directory. A series of symbolic links in the rcn.d directories, one directory for each runlevel n, control whether a script is started when entering a runlevel or stopped when leaving it. These links start with either a K or an S, followed by a two-digit number and then the name of the service, as shown in Listing 10.

Here you see that the audit and autofs services have Knn entries in all runlevels and Snn entries for both in runlevels 3 and 5. The S indicates that the service is started when that runlevel is entered, while the K entry indicates that it should be stopped. The nn component of the link name indicates the priority order in which the service should be started or stopped. In this example, audit is started before autofs, and it is stopped later.

Consult the man pages for init and inittab for more information.

Init vs. Upstart

As we have seen here, the traditional method of booting a Linux system is based on the UNIX System V init process. It involves loading an initial RAM disk (initrd) and then passing control to a program called init, a program that is usually installed as part of the sysvinit package. The init program then runs a series of scripts in a predefined order to bring up the system. If something that is expected is not available, the init process typically waits until it is. While this worked adequately for systems where everything is known and connected when the system starts, modern systems with hot-pluggable devices, network file systems, and even network interfaces that may not be available at start time present new challenges. Certainly, waiting for hardware that may not come available for a long time, or even just a relatively long time, is not desirable.

An alternative initialization process called upstart was first introduced in Ubuntu 6.10 ("Edgy Eft") in 2006. This has now supplanted the init process in Ubuntu and Fedora, among others, although vestiges of init remain and the full power of upstart may not be realized for some time yet.

In contrast to the static set of init scripts used in earlier systems, the upstart system is driven by events. Events may be triggered by hardware changes, starting or stopping or tasks, or by any other process on the system. Events are used to trigger tasks or services, collectively known as jobs. So, for example, connecting a USB drive might cause the udev service to send a block-device-added event, which would cause a defined task to check /etc/fstab and mount the drive if appropriate. As another example, an Apache web server may be started only when both a network and required filesystem resources are available.

The upstart initialization program replaces /sbin/init. Upstart jobs are defined in the /etc/init directory and its subdirectories. The upstart system will currently process /etc/inittab and System V init scripts. On systems such as recent Fedora releases, /etc/inittab is likely to contain only the id entry for the initdefault action. Recent Ubuntu systems do not have /etc/inittab by default, although you can create one if you want to specify a default runlevel.

Upstart also has the initctl command to allow interaction with the upstart init daemon. This allows you to start or stop jobs, list jobs, get status of jobs, emit events, restart the init process, and so on. Listing 11 shows how to use initctl to obtain a list of upstart jobs on a Fedora 13 system.