Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
LPI Linux Certification in a Nutshell (6 page)
System
Linux has the same concept of
runlevels
that most Unix systems offer. This concept specifies different ways to use
a system by controlling which services are running. For example, a system
that operates as a web server is configured to boot and initiate
processing in a runlevel designated for sharing data, at which point the
web server is started. However, the same system could be booted into
another runlevel used for emergency administration, when all but the most
basic services are shut down, so the web server would not run.
One common use of runlevels is to distinguish between a system that
offers only a text console and a system that offers a graphical user
interface through the
X Window System. Most end-user systems run the graphical
user interface, but a server (such as the web server just discussed) is
more secure and performs better without it.
Runlevels are specified by the integers 0 through 6. Runlevels 0 and
6 are unusual in that they specify the transitional states of shutdown and
reboot, respectively. When an administrator tells Linux to enter runlevel
0, the operating system begins a clean shutdown procedure. Similarly, the
use of runlevel 6 begins a reboot. The remaining runlevels differ in
meaning slightly among Linux distributions and other Unix systems.
When a Linux system boots, the first process it begins is the
init
process, which starts all other
processes. The
init
process is responsible for
placing the system in the default runlevel, which is usually 2, 3, or 5
depending on the distribution and the use for the machine. Typical
runlevel meanings are listed in
Table 4-1
.
Table 4-1. Typical runlevels
Runlevel | Description |
|---|---|
0 | Halt the system. Runlevel 0 is a special |
1, s, S | Single-user mode, sometimes called |
2 | Multiuser. On Debian-based systems, this |
3 | On Red Hat–based systems, this is the |
4 | Typically unused. |
5 | On Red Hat–based systems, full multiuser |
6 | Reboot the system. Just like runlevel 0, |
It is important to note that runlevels, like most things in Linux,
are completely configurable by the end user. For the purposes of the LPIC
test, it’s important to know the standard meanings of each runlevel on Red
Hat–based and Debian-based systems and how the runlevels work. However, in
a production environment, runlevels can be modified to do whatever the
system administrator desires.
Runlevel 1, the single-user runlevel, is a bare-bones
operating environment intended for system maintenance. In single-user
mode, remote logins are disabled, networking is disabled, and most
daemons are not started. Single-user mode is used for system
configuration tasks that must be performed with no user activity. One
common reason you might be forced to use single-user mode is to correct
problems with a corrupt filesystem that the system cannot handle
automatically.
If you wish to boot directly into single-user mode, you may
specify it at boot time with the kernel’s command line through your boot
loader. For instance, the
GRUB boot loader allows you to pass arbitrary parameters
to a kernel at boot time. In order to change the default runlevel, edit
the line that boots your kernel in the GRUB interactive menu, adding a1or the wordsingleto the end of the line to indicate
single-user mode. These arguments are not interpreted as kernel
arguments but are instead passed along to the init process. For example,
if your default GRUB kernel boot line looks like this:
kernel /vmlinuz-2.6.27.21-170.2.56.fc10.i686 ro root=/dev/hda1 rhgb quiet
you can force the system to boot to runlevel 1 by changing this
to:
kernel /vmlinuz-2.6.27.21-170.2.56.fc10.i686 ro root=/dev/hda5 rhgb quiet 1
or:
kernel /vmlinuz-2.6.27.21-170.2.56.fc10.i686 ro root=/dev/hda5 rhgb \
quiet single
To switch into single-user mode from another runlevel, you can
simply issue a runlevel change command with
init
:
#init 1
This is not the preferred way of taking a currently running system
to runlevel 1, mostly because it gives no warning to the existing
logged-in users. See the
explanation
of the
shutdown
command later in this
chapter to learn the preferred way of handling system shutdown.
By themselves, the runlevels listed in
Table 4-1
don’t mean much. It’s what the
init
process does as a result of a
runlevel specification or change that affects the system. The actions of
init
for each runlevel are derived from the style
of initialization in
Unix System V and are specified in a series of directories
and script files under the
/etc
directory.
When a Linux system starts, it runs a number of scripts in
/etc
to initially configure the system and switch
among runlevels.
System initialization techniques differ among Linux
distributions. The examples in this section are typical of a Red
Hat–based system. Any distribution compliant with the Linux Standards
Base (LSB) should look similar. The following describe these
files:
- /etc/rc.sysinit
or
/etc/init.d/rcS On Red Hat–based systems,
rc.sysinit
is
a monolithic system initialization script. The Debian
rcS
script does the same job by running
several small scripts placed in two different directories. In each
case, the script is launched by
init
at boot
time. It handles some essential chores to prepare the system for
use, such as mounting filesystems. This script is designed to run
before any system daemons are started.- /etc/rc.local
Not used on
Debian-based systems. On
Red Hat–based systems, this file is a script that is
called after all other
init
scripts (after
all system daemons are
started
). It contains local
customizations affecting system startup and provides an
alternative to modifying the other
init
scripts. Many administrators prefer to avoid changing
rc.sysint
because those changes will be
lost during a system upgrade. The contents of
rc.local
are not lost in an
upgrade.- /etc/rc
This file is a script that is used to change between
runlevels. It is not provided on Debian.
The job of starting and stopping system services (also known as
daemons
, which are intended to always
run in the background, such as web servers) is handled by the files and
symbolic links in
/etc/init.d
and
by a series of runlevel-specific directories named
/etc/rc0.d
through
/etc/rc6.d
. These are used as follows:
- /etc/init.d
This directory contains individual startup/shutdown scripts
for each service on the system. For example, the script
/etc/init.d/httpd
is a Bourne shell
script that performs some sanity checks before starting or
stopping the
Apache web server.These scripts have a standard basic form and take a single
argument. Valid arguments include at least the wordsstartandstop. Additional arguments are sometimes
accepted by the script; examples arerestart,status, and sometimesreload(to ask the service to reread its
configuration file without exiting).Administrators can use these scripts directly to start and
stop services. For example, to restart Apache, an administrator
could issue commands like these:#
/etc/init.d/httpd stop#/etc/init.d/httpd startor simply:
#
/etc/init.d/httpd restartEither form would completely shut down and start up the web
server. To ask Apache to remain running but reread its
configuration file, you might enter:#
/etc/init.d/httpd reloadThis has the effect of sending the
SIGHUP signal to the running
httpd
process, instructing it
to initialize. Signals such as SIGHUP are covered in
Chapter 6
.If you add a new service through a package management tool
such as
rpm
or
dpkg
, one of these
initialization files may be installed automatically for you. In
other cases, you may need to create one yourself or, as a last
resort, place startup commands in the
rc.local
file.It’s important to remember that these files are simply shell
scripts that wrap the various options accepted by the different
daemons on Linux. Not all Linux daemons recognize the command-line
argumentsstop,start, etc., but the scripts in
/etc/init.d
make it easy to
manage your running daemons by stan
dardizing
the commands that you use
to control them.- The directories
/etc/rc0.d
through
/etc/rc6.d The initialization scripts in
/etc/init.d
are not directly executed
by the
init
pro
cess
. Instead, each of the
directories
/etc/rc0.d
through
/etc/rc6.d
contains
symbolic (soft) links to the scripts in the
/etc/init.d
directory. (These symbolic links
could also be files, but using script files in each of the
directories would be an administrative headache, because changes
to any of the startup scripts would mean identical edits to
multiple files.) When the
init
process enters
runlevelN, it examines all of the
links in the associated
rcN.d
directory. These links are given
special names in the forms of
KNNname
and
SNNname
, described as follows:- K
and
S
prefixes These letters stand for
kill
and
start
, respectively. Each runlevel
defines a state in which certain services are running and
all others are not. The
S
prefix is used to mark files
for all services that are to be running (started) for the
runlevel. The
K
prefix
is used for all other services, which should not be
running.NNSequence number. This part of the link name is
a two-digit integer (with a leading zero, if necessary). It
specifies the relative order for services to be started or
stopped. The lowest number represents the first script
executed by
init
, and the largest
number is the last. There are no hard-and-fast rules for
choosing these numbers, but it is important when adding a
new service to be sure that it starts after any other
required services are already running. If two services have
an identical start order number, the order is indeterminate
but probably alphabetical.- name
By convention, the name of the script being linked to.
init
does not use this name, but
including it makes maintenance easier for human
readers.
As an example, when
init
enters the
default runlevel (3 for the sake of this example) at boot time,
all of the links with the
K
and
S
prefixes in
/etc/rc3.d
will be executed in the
order given by their sequence number (
S10network
,
S12sys
log
,
and so on). Links that start with
S
will be run with the single argumentstartto launch their
respective services, and links that start with
K
will be run with the single argumentstopto stop the respective
service. Since K comes before S alphabetically, the
K
services are stopped before the
S
services are
started
. After the last of the
scripts is executed, the requirements for runlevel 3 are
satisfied.- K