Professional Documents
Culture Documents
and reboot
Bring your system to life
Learn to shut down or reboot your Linux system, warn users that the system is going down,
and switch to a more or less restrictive runlevel. You can use the material in this article to study
for the LPIC-1: Linux Server Professional Certification, or just to learn about shutting down,
rebooting, and changing runlevels. The material corresponds to the LPI April 2015 Version 4.0
objectives.
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 or boot target. Learn to:
Unless otherwise noted, the examples in this article use a Slackware 13.37 system with 2.6.37
kernel. The upstart examples use Ubuntu 14.04 LTS with a 3.16.0 kernel. The systemd examples
use Fedora 22 with a 4.0.4 kernel. Your results on other systems may differ.
Running Linux
Most of the time a Linux system runs as a multiuser system, often as a server with many different
processes running under several different user ids. Sometimes it has a graphical user interface
and serves mostly a single user, while at other times it is a headless server working for many
users. When you need to do some kinds of system maintenance you don't want all those users
trying to get things done, so you need to be able to run the system with a single user rather than
many. You also need to switch to this mode cleanly, giving appropriate warnings to logged-in users.
And you need to get back into regular operation as quickly as possible. This article shows you
how.
See "Learn Linux, 101: A roadmap for LPIC-1" for a description of and link to each tutorial in
this series. The roadmap is in progress and reflects the version 4.0 objectives of the LPIC-1
exams as updated April 15th, 2015. As tutorials are completed, they will be added to the
roadmap.
This article helps you prepare for Objective 101.3 in Topic 101 of the Linux Server Professional
(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 and systemd
systems are changing many things that might be familiar to users of the traditional System V init
process (see Beyond Init for details). This article commences with discussion of the traditional
System V init process and its runlevels. We then discuss upstart and systemd which are newer
initialization processes.
System V runlevels
The traditional System V Runlevels define what tasks can be accomplished in the current state (or
runlevel) of a Linux system. Traditional Linux systems support three basic runlevels, plus one or
more runlevels for normal operation. The basic runlevels are shown in Table 1.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 2 of 18
ibm.com/developerWorks/ developerWorks®
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.
Edit this value if you want your system to start in a different runlevel, say runlevel 4.
Changing runlevels
There are several ways to change runlevels. To make a permanent change, you can edit /etc/
inittab and change the default level that 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 GRUB 2) 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
boot CentOS. We've broken the long kernel line for publication using the backslash (\) character.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 3 of 18
developerWorks® ibm.com/developerWorks/
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 CentOS 6 system looks like Figure 1.
In this example, you should now see the root, kernel, and initrd lines displayed. Move the cursor
to the line starting with "kernel" and press 'e' to edit the line. The GRUB screen on our CentOS 6
system now looks like Figure 2.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 4 of 18
ibm.com/developerWorks/ developerWorks®
Finally, move the cursor to the end of the line, and add a space and the digit '3'. You may remove
'quiet' if you wish, or modify any other parameters as needed. The GRUB screen on our CentOS 6
system now looks like Figure 3.
Finally, press Enter to save the changes, then type 'b' to boot the system.
Notes:
1. The steps for doing this using LILO or GRUB 2 differ from those for GRUB, but the basic
principle of editing the way the kernel is started remains. Even GRUB screens on other
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 5 of 18
developerWorks® ibm.com/developerWorks/
systems or other distributions may look quite different to those shown here. Prompts will
usually be available to help you.
2. On systems that use either upstart or systemd, runlevels are simulated and some things may
not work exactly as you might expect. This is particularly true if you try to change a runlevel by
using telinit
Once you have finished your setup work in runlevel 3, you will probably want to switch to runlevel
5. On a traditional System V init system, you do not need to reboot the system. You can use the
telinit command to switch to another runlevel. Use the runlevel command to show both the
previous runlevel and the current one. If the first output character is 'N', the runlevel has not been
changed since the system was booted. Listing 3 illustrates verifying and changing the runlevel.
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 on a system that
uses System V init, such as Slackware 37, you will see that it really is a symbolic link to the init
command. We illustrate this in Listing 5. If your system uses upstart of systemd this will probably
not be the case.
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 5 to 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
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 6 of 18
ibm.com/developerWorks/ developerWorks®
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 -r option 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.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 7 of 18
developerWorks® ibm.com/developerWorks/
Notice in the last example that our broadcast message came out at 18:11, but we asked for
shutdown at 23:59, some 6.5 hours later. The traditional System V implementation of shutdown,
does not send a warning message if the shutdown is more than 15 minutes away. Rather it waits
till 15 minutes before the scheduled shutdown then sends the message. Listing 7 shows a System
V example on Slackware 37 and also shows the use of the -t option to increase the default delay
between SIGTERM and SIGKILL signals from 5 seconds to 60 seconds.
Time to do backups
The system is going DOWN to maintenance mode in 15 minutes!
[root@atticf22 ~]# echo -e "We are experiencing system problemsOutage rescheduled to 02:30" | wall
As we said earlier, it is also possible to use telinit (or init) to shut down or reboot the system.
As with other uses of telinit, 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.
If you don't want to upset your users with sudden system outages, you need to notify them using
wall and all other means at your disposal.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 8 of 18
ibm.com/developerWorks/ developerWorks®
For additional options that you may use with these commands, as well as more detailed
information on their operation, consult the man page.
System V /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 that we saw earlier?
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 9 shows the full inittab from our Slackware 37 system.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 9 of 18
developerWorks® ibm.com/developerWorks/
rc:2345:wait:/etc/rc.d/rc.M
# Dialup lines:
#d1:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS0 vt100
#d2:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS1 vt100
# End of /etc/inittab
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 may 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.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 10 of 18
ibm.com/developerWorks/ developerWorks®
Listing 10 shows just the entry for Ctrl-Alt-Delete from Listing 9. 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/M script (or command) whenever runlevel 2,3,4, or 5
are 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, usually 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. Some examples from an older system are
shown in Listing 11.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 11 of 18
developerWorks® ibm.com/developerWorks/
/etc/rc.d/rc0.d/K72autofs
/etc/rc.d/rc0.d/K73auditd
/etc/rc.d/rc6.d/K72autofs
/etc/rc.d/rc6.d/K73auditd
/etc/rc.d/rc1.d/K72autofs
/etc/rc.d/rc1.d/K73auditd
/etc/rc.d/rc3.d/S27auditd
/etc/rc.d/rc3.d/S28autofs
[root@pinguino ~]# cd /etc/rc.d/rc5.d
[root@pinguino rc5.d]# ls -l ???a*
lrwxrwxrwx 1 root root 16 2008-04-07 11:29 S27auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 16 2008-04-01 07:51 S28autofs -> ../init.d/autofs
lrwxrwxrwx 1 root root 15 2008-04-01 14:03 S44acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root 13 2008-04-01 07:50 S95atd -> ../init.d/atd
lrwxrwxrwx 1 root root 22 2008-04-01 07:54 S96avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 17 2008-11-17 13:40 S99anacron -> ../init.d/anacron
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. Since the K and S links usually link to the
same script, the script knows whether it is entering or leaving a level by examining the link name
by which it was called.
However, Slackware uses a slightly different approach. as shown in Listing 12. Notice that the /etc/
rc[0-9].d directories are all empty. Entering a particular runlevel is controlled by a script such as the
script to go multiuser, /etc/rc.d/rc.M which is used when entering run levels 2, 3, 4, or 5.
Consult the init and inittab man pages for more information.
Beyond Init
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 is the first process in the system and has PID (Process ID) 1. It 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
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 12 of 18
ibm.com/developerWorks/ developerWorks®
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.
In the following sections of this article we will describe two alternatives to System V init, upstart
and systemd.
If you are not sure what system initialization you have, remember that the first process started on
your system has Process Id (PID) 1. Find out which program is running as PID1. If it's called "init"
then figure out which package provides it. Listing 13 shows how to do this on several systems.
ian@attic4:~$ # Slackware 37
ian@attic4:~$ ps -p 1 -o comm=
init
ian@attic4:~$ grep sbin/init /var/log/packages/*
/var/log/packages/sysvinit-2.86-x86_64-6:sbin/init.new
/var/log/packages/sysvinit-2.86-x86_64-6:sbin/initscript.sample
/var/log/packages/sysvinit-functions-8.53-x86_64-2:sbin/initlog
ian@attic4:~$ # System V style init
ian@attic-u14:~$ # Ubuntu 14
ian@attic-u14:~$ ps -p 1 -o comm=
init
ian@attic-u14:~$ dpkg -S `which init`
upstart: /sbin/init
ian@attic-u14:~$ # Upstart
With both upstart and systemd, vestiges of System V Init remain, particularly /etc/fstab and a
skeletal /etc/inittab. The concept of runlevel is not directly supported. System V commands such
as telinit are supported, but their function is mapped internally into activation and deactivation
of upstart jobs or systemd units. Needless to say, the mapping may sometimes be less than
perfect, so if you boot into runlevel 3 and then use telinit to switch to runlevel 5, your system may
or may not work exactly as it would had you rebooted. The "SysVinit to Systemd Cheatsheet" (see
Resources) can help you map the concepts and commands from System V init to systemd.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 13 of 18
developerWorks® ibm.com/developerWorks/
Upstart
A new initialization process called upstart was first introduced in Ubuntu 6.10 ("Edgy Eft") in 2006.
Fedora 9 through 14 and Red Hat Enterprise Linux (RHEL) 6 use upstart, as do distributions
derived from these. Upstart has now supplanted the init process in Ubuntu 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 14 shows how to use initctl to obtain a list of upstart jobs on a Fedora 13 system.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 14 of 18
ibm.com/developerWorks/ developerWorks®
Systemd
Another new initialization system called systemd is also emerging. Systemd was developed
by Lennart Poettering in early 2010. He described the rationale and design in a blog post (see
Related topics. Early adopters were Fedora 15, openSUSE 12.1 and Mandriva 2011 among
others. With release 15.04 Ubuntu has switched from upstart to systemd.
Many daemon processes communicate using sockets. In order to gain speed and enhance
parallelism in the system startup, systemd creates these sockets at startup, but only starts
the associated task when a connection request for services on that socket is received. In this
way, services can be started only when they are first required and not necessarily at system
initialization. Services that need some other facility will block until it is available, so only those
services that are waiting for some other process need block while that process starts.
Extending the idea of waiting for services systemd uses autofs to define mount points, so the
mount point for a file system is available, but the actual mount may be delayed until some process
attempts to open a file on the file system or otherwise use it.
These ideas not only delay startup of services until needed, they also reduce the need for
dependency checking between services, as the interface for the service can be ready long before
the service itself needs to be available.
Like upstart, systemd can process existing initialization from /etc/inittab. It can also process /etc/
fstab to control file system mounting. Native systemd initialization revolves around the concept of
units, which can be grouped into control groups or cgroups. Among the several types of units, you
may find the following:
• Service units are daemons that can be started, stopped, restarted, reloaded.
• Socket units encapsulate a socket in the file-system or on the Internet.
• Device units encapsulate a device in the Linux device tree.
• Mount units encapsulate a mount point in the file system hierarchy.
• Automount units encapsulate an automount point in the file system hierarchy.
• Target units group other units together, providing a single control unit for multiple other units.
• Snapshot units reference other units and can be used to save and roll back the state of all
services and units of the init system (for example, during suspend).
Units are configured using a configuration file, which includes the unit type as a suffix. For
example, cups.service, rpcbind.socket or getty.target. The location of system configuration files (for
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 15 of 18
developerWorks® ibm.com/developerWorks/
The systemctl command allows you to interrogate and control the systemd daemon, including
starting and stopping units or listing their status. Listing 16 illustrates the use of systemctl to
display the status of some of the systemd units on my Fedora 22 system.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 16 of 18
ibm.com/developerWorks/ developerWorks®
164 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
The last part of the unit name (such as device, path, target) is the unit type.
The systemctl command allows you to interrogate and control the system units. We show a few
examples in Listing 17 where we first interrogate the SSH server daemon (sshd.service). Then we
stop it and check the status again. Finally, we start it again.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 17 of 18
developerWorks® ibm.com/developerWorks/
Related topics
• Use the developerWorks roadmap for LPIC-1 to find the developerWorks tutorials to help you
study for LPIC-1 certification based on the LPI Version 4.0 April 2015 objectives.
• At the Linux Professional Institute website, find detailed objectives, task lists, and sample
questions for the certifications. In particular, see:
• The LPIC-1: Linux Server Professional Certification program details
• LPIC-1 exam 101 objectives
• LPIC-1 exam 102 objectives
Always refer to the Linux Professional Institute website for the latest objectives.
• The Linux BootPrompt-HowTo helps you understand boot parameters.
• See the Upstart overview for more information on upstart.
• See Rethinking PID 1 for more information on the rationale for systemd.
• The SysVinit to Systemd Cheatsheet helps you map between System V concepts and
commands and their systemd counterparts.
• The Linux Documentation Project has a variety of useful documents, especially its HOWTOs.
Learn Linux, 101: Runlevels, boot targets, shutdown, and reboot Page 18 of 18