Preparing for Machine Reboot (Practical mod

5.7. Preparing for Machine Reboot

When using a non-production development box, it is OK to start and stop the web server by hand when necessary. On a production system, however, it is possible that the machine on which the server is running will have to be rebooted. When the reboot is completed, who is going to remember to start the server? It is easy to forget this task, and what happens if no one is around when the machine is rebooted? (Some OSs will reboot themselves without human intervention in certain situations.)

After the server installation is complete, it is important to remember that a script to perform the server startup and shutdown should be put in a standard system location—for example, /etc/rc.d under Red Hat Linux, or /etc/init.d/apache under Debian GNU/Linux.

This book uses Red Hat-compatible Linux distributions in its examples. Let's step aside for a brief introduction to the System V (SysV) init system that many Linux and other Unix flavors use to manage starting and stopping daemons. (A daemon is a process that normally starts at system startup and runs in the background until the system goes down.)

The SysV init system keeps all its files in the /etc/rc.d/ directory. This directory contains a number of subdirectories:

panic% find /etc/rc.d -type d
/etc/rc.d
/etc/rc.d/init.d
/etc/rc.d/rc0.d
/etc/rc.d/rc1.d
/etc/rc.d/rc2.d
/etc/rc.d/rc3.d
/etc/rc.d/rc4.d
/etc/rc.d/rc5.d
/etc/rc.d/rc6.d

/etc/rc.d/init.d contains many scripts, one for each service that needs to be started at boot time or when entering a specific runlevel. Common services include networking, file sharing, mail servers, web servers, FTP servers, etc.

When the system boots, the special init script runs all scripts for the default runlevel. The default runlevel is specified in the /etc/inittab file. This file contains a line similar to this one:

id:3:initdefault:

The second column indicates that the default runlevel is 3, which is the default for most server systems. (5 is the default for desktop machines.)

Let's now see how the scripts are run. We'll first look at the contents of the /etc/rc.d/rc3.d directory:

panic% ls -l /etc/rc.d/rc3.d
lrwxrwxrwx 1 root root 13 Jul  1 01:08 K20nfs -> ../init.d/nfs
lrwxrwxrwx 1 root root 18 Jul  1 00:54 K92ipchains -> ../init.d
lrwxrwxrwx 1 root root 17 Jul  1 00:51 S10network -> ../init.d/network
lrwxrwxrwx 1 root root 16 Jul  1 00:51 S30syslog -> ../init.d/syslog
lrwxrwxrwx 1 root root 13 Jul  1 00:52 S40atd -> ../init.d/atd
lrwxrwxrwx 1 root root 15 Jul  1 00:51 S40crond -> ../init.d/crond
lrwxrwxrwx 1 root root 15 Jul  1 01:13 S91httpd_docs -> ../init.d/httpd_docs
lrwxrwxrwx 1 root root 15 Jul  1 01:13 S91httpd_perl -> ../init.d/httpd_perl
lrwxrwxrwx 1 root root 17 Jul  1 00:51 S95kheader -> ../init.d/kheader
lrwxrwxrwx 1 root root 11 Jul  1 00:51 S99local -> ../rc.local

(Only part of the output is shown here, since many services are started and stopped at runlevel 3.)

There are no real files in the directory. Instead, each file is a symbolic link to one of the scripts in the init.d directory. The links' names start with a letter (S or K) and a two-digit number. S specifies that the script should be run when the service is started and K specifies that the script should be run when the service is stopped. The number following S or K is there for ordering purposes: init will start services in the order in which they appear.

init runs each script with an argument that is either start or stop, depending on whether the link's name starts with S or K. Scripts can be executed from the command line; the following command line will stop the httpd server:

panic# /etc/rc.d/init.d/httpd_perl stop

Unfortunately, different Unix flavors implement different init systems. Refer to your system's documentation.

Now that we're familiar with how the init system works, let's return to our discussion of apachectl scripts.

Generally, the simplest solution is to copy the apachectl script to the startup directory or, better still, create a symbolic link from the startup directory to the apachectl script. The apachectl utility is in the same directory as the Apache executable after Apache installation (e.g., /home/httpd/httpd_perl/bin). If there is more than one Apache server, there will need to be a separate script for each one, and of course they will have to have different names so that they can coexist in the same directory.

On one of our Red Hat Linux machines with two servers, we have the following setup:

/etc/rc.d/init.d/httpd_docs
/etc/rc.d/init.d/httpd_perl
/etc/rc.d/rc3.d/S91httpd_docs -> ../init.d/httpd_docs
/etc/rc.d/rc3.d/S91httpd_perl -> ../init.d/httpd_perl
/etc/rc.d/rc6.d/K16httpd_docs -> ../init.d/httpd_docs
/etc/rc.d/rc6.d/K16httpd_perl -> ../init.d/httpd_perl

The scripts themselves reside in the /etc/rc.d/init.d directory. There are symbolic links to these scripts in /etc/rc.d/rc*.d directories.

When the system starts (runlevel 3), we want Apache to be started when all the services on which it might depend are already running. Therefore, we have used S91. If, for example, the mod_perl-enabled Apache issues a connect_on_init( ), the SQL server should be started before Apache.

When the system shuts down (runlevel 6), Apache should be one of the first processes to be stopped—therefore, we have used K16. Again, if the server does some cleanup processing during the shutdown event and requires third-party services (e.g., a MySQL server) to be running at the time, it should be stopped before these services.

Notice that it is normal for more than one symbolic link to have the same sequence number.

Under Red Hat Linux and similar systems, when a machine is booted and its runlevel is set to 3 (multiuser plus network), Linux goes into /etc/rc.d/rc3.d/ and executes the scripts to which the symbolic links point with the start argument. When it sees S87httpd_perl, it executes:

/etc/rc.d/init.d/httpd_perl start

When the machine is shut down, the scripts are executed through links from the /etc/rc.d/rc6.d/ directory. This time the scripts are called with the stop argument, like this:

/etc/rc.d/init.d/httpd_perl stop

Most systems have GUI utilities to automate the creation of symbolic links. For example, Red Hat Linux includes the ntsysv and tksysv utilities. These can be used to create the proper symbolic links. Before it is used, the apachectl or similar scripts should be put into the init.d directory or an equivalent directory. Alternatively, a symbolic link to some other location can be created.

However, it's been reported that sometimes these tools mess up and break things. Therefore, the robust chkconfig utility should be used instead. The following example shows how to add an httpd_perl startup script to the system using chkconfig.

The apachectl script may be kept in any directory, as long as it can be the target of a symbolic link. For example, it might be desirable to keep all Apache executables in the same directory (e.g., /home/httpd/httpd_perl/bin), in which case all that needs to be done is to provide a symbolic link to this file:

panic% ln -s /home/httpd/httpd_perl/bin/apachectl /etc/rc.d/init.d/httpd_perl

Edit the apachectl script to add the following lines after the script's main header:

# Comments to support chkconfig on RedHat Linux
# chkconfig: 2345 91 16
# description: mod_perl enabled Apache Server

Now the beginning of the script looks like:

#!/bin/sh
#
# Apache control script designed to allow an easy command line
# interface to controlling Apache.  Written by Marc Slemko,
# 1997/08/23

# Comments to support chkconfig on Red Hat Linux
# chkconfig: 2345 91 16
# description: mod_perl-enabled Apache Server

#
# The exit codes returned are:
# ...

Adjust the line:

# chkconfig: 2345 91 16

to suit your situation. For example, the setting used above says the script should be started in levels 2, 3, 4, and 5, that its start priority should be 91, and that its stop priority should be 16.

Now all you need to do is ask chkconfig to configure the startup scripts. Before doing so, it is best to check what files and links are in place:

panic% find /etc/rc.d | grep httpd_perl

/etc/rc.d/init.d/httpd_perl

This response means that only the startup script itself exists. Now execute:

panic% chkconfig --add httpd_perl

and repeat the find command to see what has changed:

panic% find /etc/rc.d | grep httpd_perl

/etc/rc.d/init.d/httpd_perl
/etc/rc.d/rc0.d/K16httpd_perl
/etc/rc.d/rc1.d/K16httpd_perl
/etc/rc.d/rc2.d/S91httpd_perl
/etc/rc.d/rc3.d/S91httpd_perl
/etc/rc.d/rc4.d/S91httpd_perl
/etc/rc.d/rc5.d/S91httpd_perl
/etc/rc.d/rc6.d/K16httpd_perl

The chkconfig program has created all the required symbolic links using the startup and shutdown priorities as specified in the line:

# chkconfig: 2345 91 16

If for some reason it becomes necessary to remove the service from the startup scripts, chkconfig can perform the removal of the links automatically:

panic% chkconfig --del httpd_perl

By running the find command once more, you can see that the symbolic links have been removed and only the original file remains:

panic% find /etc/rc.d | grep httpd_perl

/etc/rc.d/init.d/httpd_perl

Again, execute:

panic% chkconfig --add httpd_perl

Note that when using symbolic links, the link name in /etc/rc.d/init.d is what matters, not the name of the script to which the link points.