Advanced.Linux.Networking..Roderick.Smith [Electronic resources] نسخه متنی

Using SysV
Startup Scripts

AT&T's System V, or SysV, UNIX set many
of the standards used on today's UNIX and Linux systems. One of these was a
method of starting system services, including servers. In the SysV scheme, each
service comes with a script that can be used to start or stop the service by
passing the script the start or stop parameter, respectively. Many of these startup scripts support
additional parameters, such as restart to shut down the server and start
it up again (say, to implement a changed configuration).

NOTE

align=left border=0>

SysV startup scripts can and do start programs other than network servers. In this book, I use the terms service and daemon to refer to a program or OS feature that's more-or-less constantly accessible, whether or not it interacts with the network; server is used to refer to programs that respond to network requests, or to a computer that runs server programs. Most of the services discussed in this book are servers. Not everybody uses these terms in precisely this way; for instance, some people use service to refer exclusively to what I call server programs.

The SysV startup scheme is closely tied to
the runlevel of the computer. Each runlevel is
associated with a specific set of startup scripts, and hence with a specific
set of services that the system runs. (SysV scripts can start more than just
network servers; they can start system loggers, filesystem handlers, and so
on.) Thus, configuring servers to start via SysV scripts is closely related to
configuring these runlevels. This is done by altering the names of links
to the startup scripts, as stored in directories associated with each runlevel.

Startup
Script Locations and Naming Conventions

Although the basic outline of SysV startup scripts is the same
across most distributions, there are differences in many details. Most
importantly, different distributions place the startup scripts in different
locations. They may also call scripts by different names, although these
differences are usually not too extreme. href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch04lev1sec1&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch04table01#ch04table01"> Table 4.1 summarizes these SysV layout
differences for several major Linux distributions. Note that distributions
differ in where they place the actual scripts, where they place the links to
the scripts that are associated with specific runlevels, and where they place
local startup scripts (which are discussed in more detail shortly, in the
section "href="http:// /?xmlid=0-201-77423-2/ch04lev1sec4#ch04lev1sec4"> Using Local Startup Scripts "). In the
case of script links, a ?
in the directory name refers to a number from 0 to 6 corresponding to the
runlevel.

NOTE

align=left border=0>

The runlevel is a number from 06 that corresponds to a particular set of running services. It's described in more detail shortly, in the section "href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch04lev1sec1&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch04lev2sec4#ch04lev2sec4"> Setting and Changing the Runlevel ." For now, know that the computer enters a specific runlevel when it starts, which means it runs the SysV startup scripts associated with that runlevel. You can also change runlevels after the computer has booted.

NOTE

align=left border=0>

Throughout this chapter, I refer to SysV script directories and SysV script link directories. These are the locations outlined in href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch04lev1sec1&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch04table01#ch04table01"> Table 4.1 , and it's important that you modify files in the appropriate location if you choose to do so.

Several distributions (notably Red Hat, Mandrake, TurboLinux,
and to a lesser extent Caldera) are quite similar to each other, particularly
in their placement of SysV scripts ( /etc/rc.d/init.d )
and the links to those scripts ( /etc/rc.d/rc?.d ).
Others place the scripts in slightly different locations. Slackware is the most
unusual in this respect. Rather than running individual scripts in a directory
named after a runlevel, Slackware uses a single script for each runlevel. For
instance, the /etc/rc.d/rc.4
script controls the startup of runlevel 4.

For most Linux distributions (Slackware being the major exception),
the links in the SysV startup script link directories are named in a very
particular way. Specifically, the filename takes the form C##name , where C is a character ( S or K ),
## is a two-digit number,
and name is a name that's
traditionally the same as the corresponding script in the SysV script
directory. For instance, the link filename might be S10network or K20nfs filenames
that correspond to the network
and nfs scripts, respectively.
As you might guess, this naming scheme isn't random. The name portion of the link filename
helps you determine what the script does; it's usually named after the original
script. The leading character indicates whether the computer will start or kill
(for S and K , respectively) the script upon entering
the specified runlevel. Thus, S10network
indicates that the system will start whatever the network script starts (basic networking features, in fact),
and K20nfs shuts down whatever
the nfs script controls (the NFS
server, in reality). The numbers indicate the sequence in which these actions
are to be performed. Thus, S10network
starts networking before S55sshd
starts the secure shell (SSH) server. Similar rules apply for shutdown ( K ) links.

The names and numbers of the startup and shutdown links vary
from one distribution to another. For instance, Mandrake uses S10network to start its basic networking
features, but Debian uses S35networking
for this function. Similar differences may exist for the scripts that launch
specific servers. What's important is that all the necessary servers and
processes are started in the correct order. Many networking tools must be
started after basic networking features are started, for instance. It's
generally not wise to change the order in which startup and shutdown scripts
execute, unless you understand this sequence and the consequences of your
changes.

One additional wrinkle requires mention: SuSE uses the /etc/rc.config file to control the SysV
startup process. This file contains sections pertaining to major servers that
can be started via the SysV process, and if a server is not listed for startup
(via a line of the form START_SERVERNAME="yes" ),
SuSE doesn't start that server, even if its link name begins with S . Caldera uses a similar scheme for a few
servers, but uses files in /etc/sysconfig/daemons
named after the servers in question. The ONBOOT
line in each of these files determines whether the system starts the server.
Many startup scripts ignore this option in Caldera, though.

Manually
Enabling or Disabling Startup Scripts

If you find that you need to enable or disable a server that's
started through a SysV startup script, one way to proceed is to adjust the
startup scripts or the links to them. One approach to disabling a server is to
remove the startup script from the SysV script directory. This is a quick fix
that affects all runlevels, but it's rather inelegant. It also doesn't help you
if you want to start a server rather than disable one.

A more elegant solution is to rename the link to the startup
script in the SysV link directory that corresponds to your current runlevel.
For instance, to disable a server, rename it so that it starts with K rather than S ; to enable it, reverse this process. The difficulty with
this procedure is that the sequence number isn't likely to be the same when
killing the server as when starting it. One way around this potential pitfall
is to locate all the links to the script in all the runlevels. If any of the
other runlevels sport the configuration you want, you've found the sequence
number. For instance, the following command finds all the links for the Postfix
mail server startup scripts on a Mandrake system:

$ find /etc/rc.d -name "*postfix"

/etc/rc.d/rc0.d/K30postfix /etc/rc.d/rc1.d/K30postfix /etc/rc.d/rc2.d/S80postfix /etc/rc.d/rc3.d/S80postfix /etc/rc.d/rc4.d/S80postfix /etc/rc.d/rc5.d/S80postfix /etc/rc.d/rc6.d/K30postfix /etc/rc.d/init.d/postfix
This sequence shows that Postfix is started with a sequence
number of 80 in runlevels 2 through 5, and shut down with a sequence number of
30 in runlevels 0, 1, and 6. If you wanted to disable Postfix in runlevel 3,
you could do so by renaming S80postfix
to K30postfix in that runlevel's
directory.

If you want to temporarily
start or stop a server, or if you want to initiate a change immediately without
restarting the computer or adjusting the runlevel, you can do so by running the
startup script along with the start
or stop parameters. For
instance, to stop Postfix immediately, you could type the following command on
a Mandrake system:

# /etc/rc.d/init.d/postfix stop
Most Linux distributions display a message reporting the
attempt to shut down the server, and the success of the operation. When
starting a SysV script, a message about the startup success appears. (In fact,
you may see these messages scroll across your screen after the kernel startup
messages when you boot your computer.) In the case of Slackware, instead of renaming, adding, or
deleting startup scripts or their links, you should edit the single startup
script file for the runlevel in question. For instance, if you want to change
the behavior of runlevel 4, you'd edit /etc/rc.d/rc.4 .
Most servers, though, aren't started in these runlevel-specific scripts;
they're started in /etc/rc.d/rc.inet2 ,
with very basic network tools started in /etc/rc.d/rc.inet1 .
To change your configuration, you'll have to manually modify these scripts as
if they were local startup scripts, as described in the section "href="http:// /?xmlid=0-201-77423-2/ch04lev1sec4#ch04lev1sec4"> Using Local Startup Scripts ."

Using
Startup Script Utilities

Some distributions include utilities that help you control
startup scripts. These tools can be very useful because they reduce the chance
of misnaming a script. For instance, an automated tool won't mistype S80postfix as s80postfix (using a lowercase s instead of an uppercase S ).
Unfortunately, not all distributions support these toolsthey're most common on
Red Hat and its derivatives, such as Mandrake. Installing one of these tools
from one distribution for use on another is unlikely to work because of the
differences in SysV script locations and startup sequence numbers.

NOTE

align=left border=0>

This section focuses on text-based startup script tools. GUI tools, as described shortly in the section "href="http:// /?xmlid=0-201-77423-2/ch04lev1sec5#ch04lev1sec5"> Using GUI Tools ," can also accomplish this task.

Using chkconfig

The SysV startup script tool with the crudest user interface
is chkconfig . This program is a
non-interactive commandyou must provide it with the information it needs to do
its job on a single command line. The syntax for the command is as follows:

chkconfig <list|add|del> [ name ] chkconfig [level levels ] name [on|off|reset]
The first format of this command is used to obtain information
on the current configuration (using list )
or to add or delete links in the SysV link script directory (using add or del ,
respectively). The second format is used to enable or disable a script in some
or all runlevels by changing the name of the SysV link, as described earlier.
Some examples will help clarify the use of this command.

Suppose you want to know how Postfix is configured. If you
know the Postfix startup script is called postfix ,
you could enter the following command to check its configuration:

# chkconfig list postfix postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off
This output shows the status of Postfix in each of the seven
runlevels. You can verify this by using the find
command described earlier. When chkconfig
shows an on value, the startup
link filename should start with S ,
and when chkconfig shows an off value, the startup link filename
should start with K .

If you type chkconfig
list without specifying a particular startup script filename, chkconfig shows the status for all the
startup scripts, and possibly for servers started through xinetd as well, if your system uses xinetd .

The add and del options add links if they don't exist
or delete them if they do exist, respectively. Both these options require that
you specify the name of the original startup script. For instance, chkconfig del postfix removes all the
Postfix SysV startup script links. The result is that Linux won't start the
server through a SysV startup script, or attempt to change a server's status
when changing runlevels. You might do this if you wanted to start a server
through a super server or local configuration script. You might use the add parameter to reverse this change.

You'll probably make most chkconfig
changes with the on , off , or reset
options. These enable a server, disable a server, or return the server to its
default setting for a specified runlevel. (If you omit the level option, the change applies to all runlevels.) For instance, suppose you want to
disable Postfix in runlevel 3. You could do so by typing the following command:

# chkconfig level 3 postfix off
This command won't return any output, so if you feel the need
to verify that it's worked, you should use the list
option or look for a changed filename in the startup script link directory. You
can enable a server by using on
rather than off . If you want to
affect more than one runlevel, you can do so by listing all the runlevels in a
single string, as in 345 for
runlevels 3, 4, and 5. If you've experimented with settings and want to return
them to their defaults, you can use the reset
option:

# chkconfig postfix reset
This command will reset the SysV startup script links for
Postfix to their default values. You can reset the default for just one
runlevel by including the level
levels option as the
first parameter to the command.

Although chkconfig
is generally thought of as a way to manage SysV startup scripts, it can also
work on xinetd configurations on
many systems. If chkconfig is
configured to treat, say, your FTP server as one that's launched via a super
server, you can use it to manipulate this configuration much as if the FTP
server were launched through SysV startup scripts. The difference is that the level levels
parameter won't work, and the list
option doesn't show runlevel information. Instead, any server started through a
super server will run in those runlevels in which xinetd runs. Furthermore, the add and del
options work just like on and off , respectively; the /etc/xinetd.d configuration files aren't
deleted, only disabled, as described in the upcoming section, "href="http:// /?xmlid=0-201-77423-2/ch04lev1sec3#ch04lev1sec3"> Using xinetd ."

When you change the SysV configuration with chkconfig , it does not automatically alter the servers that are running.
For instance, if you reconfigure your system to disable sshd , that server will not be immediately
shut down without manual intervention of some sort, such as running the SysV
startup script with the stop
option to stop the server.

Using
ntsysv

The ntsysv
program provides a text-based menu environment for manipulating server startup.
To run the program, type its name, optionally followed by level levels ,
where levels is one or
more runlevels you want to modify. If you omit this parameter, ntsysv modifies the configuration only for
the current runlevel. Either way, the result should resemble href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch04lev1sec1&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch04fig01#ch04fig01"> Figure 4.1 .

Figure 4.1. The ntsysv program provides an easy-to-use interface for SysV
configuration.

width=500 height=262 src="/image/library/english/10035_image002.gif" > The ntsysv
display shows all the servers that have SysV startup scripts. Some versions
also display servers started through xinetd .
To enable or disable a server, use the arrow keys on your keyboard to move the
cursor to the server you want to adjust, then press the spacebar to toggle the
server on or off. An asterisk ( * )
in the box to the left of the server name indicates that the server is active;
an empty box indicates that the server is disabled. When you're done making
changes, use the Tab key to highlight the OK button, then press the Enter key
to exit from the program and save your changes.

As with chkconfig ,
you can't adjust the specific runlevels in which servers mediated by a super
server are run, except by changing the runlevels for the super server itself. Also,
disabling a server won't cause it to shut down immediately; you must do that by
manually shutting the server down, as described earlier, or by restarting the
super server, if your target server is handled by the super server.

Setting
and Changing the Runlevel

The preceding discussion has referred to the runlevel, but
with only a minimal description of what it is. The runlevel and SysV startup
scripts are tied together quite intimately. When the computer boots, it enters
a specific runlevel. Ultimately, what this means is that the computer executes
the startup scripts to which the links in the SysV script link directories
point. More specifically, Linux passes the start
parameter to the scripts whose links start with S , and passes the stop
parameter to those whose links begin with K .

How does Linux know what runlevel to enter when it boots,
though? That's set in the /etc/inittab
file, which is the configuration file for init ,
which is the first process that Linux runs and the progenitor of all other processes.
Specifically, /etc/inittab
contains a line such as the following:

id:5:initdefault:

The leading id
is the key to identifying this line, but the following number ( 5 in this example) is what you'll use to permanently set the runlevel. If you change this
value and reboot, the computer will come up in a different runlevel. Runlevels
0, 1, and 6 have special meaningsthey correspond to a system shutdown, a
single-user mode, and a system reboot, respectively. Runlevels 2 through 5 are
normal runlevels, but their precise meanings vary from one distribution to
another. For Caldera, Red Hat, Mandrake, SuSE 7.3, and TurboLinux, runlevel 3
is a normal text-mode startup (X is not
started), and runlevel 5 is a GUI login mode (X is
started, and a GUI login program is run). Earlier versions of SuSE use
runlevels 2 and 3 instead of 3 and 5, and Slackware uses 3 and 4 for text-mode
and GUI logins. By default, Debian doesn't run any SysV scripts differently in
different normal operational runlevels, although it runs fewer text-mode login
tools in runlevels above 3 (this detail is handled by subsequent lines of /etc/inittab ). Most distributions include
a series of comments in their /etc/inittab
files describing the function of each runlevel, so look for that if you need more
information or are using a distribution I don't discuss in this book.

WARNING

align=left border=0>

Do not set the default runlevel to 0 or 6. These values will cause the computer to immediately shut down or reboot, respectively, upon booting. Either action renders the computer unusable, although you could correct it by using an emergency boot disk or other recovery method or tools, and editing /etc/inittab to correct the error.

If you want to change the runlevel
temporarily, you can do so with the telinit command ( init also
works on most systems). The syntax for this command is as follows:

telinit [-t seconds ] [ runlevel ]
When you change runlevels, it's possible that
certain processes will have to be killed. Linux can do this through either a SIGTERM or a SIGKILL signal. The former is a more polite way of doing the job; it lets the program
close its own files and so on. SIGKILL , by contrast, unceremoniously
kills the program, which can lead to file corruption. When you change
runlevels, telinit first tries to use a SIGTERM . Five seconds later, if a process
hasn't quit, telinit sends a SIGKILL . If specified, the -t seconds parameter
changes this interval. In most cases, the default five seconds is adequate.

The runlevel specification is a single-character code for the runlevel. Most obviously, you
can provide a runlevel number. There are certain other characters you can pass
that have special meaning, however:

a , b , or c Some entries in /etc/inittab use runlevels of a , b , or c for special purposes. If you specify this option to telinit , the
program only handles those /etc/inittab entries; the system's runlevel is not changed.

Q or q If you
pass one of these values as the runlevel , telinit reexamines the /etc/inittab file and initiates any changes.

S or s This
option causes the system to change into a single-user mode.

U or u This
option causes the init process to restart itself, without reexamining the /etc/inittab file.

Why would you want to change the runlevel? Changing
the default runlevel allows you to control which servers start up by default. On
most distributions, the most important of these is the X server. This is
usually started by a special line towards the end of /etc/inittab ,
not through a SysV startup script, although some use a SysV startup script for
XDM to do the job. Changing the runlevel while the computer is running allows
you to quickly enable or disable a set of servers, or change out of GUI mode if
you want to temporarily shut down X when your system is configured to start it
automatically.