System Startup and Shutdown Mechanism

Startup and shutdown scripts for HP-UX 11.x are based on a mechanism that separates the actual startup and shutdown scripts from configuration information. In order to modify the way your system starts or stops, you don't have to modify scripts, which in general is considered somewhat risky; you can instead modify configuration variables . The startup and shutdown sequence is based on an industry standard that is similar to many other UNIX-based systems, so your knowledge of HP-UX applies to many other systems.

Startup and shutdown are going to become increasingly more important to you as your system administration work becomes more sophisticated. As you load and customize more applications, you will need more startup and shutdown knowledge. What I do in this section is give you an overview of startup and shutdown and the commands you can use to control your system.

The following components are in the startup and shutdown model:

Execution Scripts
	Execution scripts read variables from configuration variable files and run through the startup or shutdown sequence. These scripts are located in /sbin/init.d .
Configuration Variable Scripts
	These are the files you would modify to set variables that are used to enable or disable a subsystem or to perform some other function at the time of system startup or shutdown. These are located in /etc/rc.config.d .
Link Files	These files are used to control the order in which scripts execute. These are actually links to execution scripts to be executed when moving from one run level to another. These files are located in the directory for the appropriate run level, such as /sbin/rc0.d for run level 0, /sbin/rc1.d for run level 1, and so on.
Sequencer Script
	This script invokes execution scripts based on run-level transition. This script is located in /sbin/rc .

Figure 7-1 shows the directory structure for startup and shutdown scripts.

Figure 7-1. Organization of Startup and Shutdown Files

Execution scripts perform startup and shutdown tasks . /sbin/rc invokes the execution script with the appropriate start or stop arguments, and you can view the appropriate start or stop messages on the console. The messages you see will have one of the three following values:

OK	This indicates that the execution script started or shut down properly.
FAIL	A problem occurred at startup or shutdown.
N/A	The script was not configured to start.

In order to start up a subsystem, you would simply edit the appropriate configuration file in /etc/rc.config.d .

Let's take a look at an example startup and shutdown file for an application loaded onto an HP-UX system that is widely used for Internet applications called Cold Fusion. Like many applications loaded on HP-UX systems, Cold Fusion installs startup and shutdown scripts as a standard part of the installation of the product.

As mentioned earlier, the script used as part of the startup and shutdown process is in /etc/init.d . In our case, the name of the program is /etc/init.d/coldfusion and is shown in the following listing:

 #  cat /sbin/init.d/coldfusion  #!/bin/sh # # Start the Cold Fusion servers # # set at install CFHOME=/apps/coldfusion CFBIN=$CFHOME/bin export CFHOME # # Start/stop processes for Cold Fusion # rval=0 case "" in     start_msg)         print "Starting ColdFusion Application Server"         ;;     stop_msg)         print "Stopping ColdFusion Application Server"         ;;     'start')         #First, check "on/off switch", to set CF_AUTOSTART, in config.d file.         RCFILE=/etc/rc.config.d/coldfusion         if [ -f $RCFILE ] ; then                 . $RCFILE         else                 print "Warning: $RCFILE defaults file missing."                 print "         Starting ColdFusion by default."                 CF_AUTOSTART=1         fi         # Start CF if switch is on.         if [ "$CF_AUTOSTART" -eq 1 ]; then             if [ -x $CFBIN/start ]; then                 $CFBIN/start                 rval=$?             else                 print "Error: ColdFusion startup script $CFBIN/start missing."                 print "       ColdFusion not started."                 rval=1             fi         else             print "Notice: ColdFusion startup disabled in $RCFILE"             rval=2         fi         ;;     'stop')         if [ -x $CFBIN/stop ]; then                 $CFBIN/stop -force         fi         ;;     *)         echo "Usage: 
 #  cat /sbin/init.d/coldfusion  #!/bin/sh # # Start the Cold Fusion servers # # set at install CFHOME=/apps/coldfusion CFBIN=$CFHOME/bin export CFHOME # # Start/stop processes for Cold Fusion # rval=0 case "$1" in start_msg) print "Starting ColdFusion Application Server" ;; stop_msg) print "Stopping ColdFusion Application Server" ;; 'start') #First, check "on/off switch", to set CF_AUTOSTART, in config.d file. RCFILE=/etc/rc.config.d/coldfusion if [ -f $RCFILE ] ; then . $RCFILE else print "Warning: $RCFILE defaults file missing." print " Starting ColdFusion by default." CF_AUTOSTART=1 fi # Start CF if switch is on. if [ "$CF_AUTOSTART" -eq 1 ]; then if [ -x $CFBIN/start ]; then $CFBIN/start rval=$? else print "Error: ColdFusion startup script $CFBIN/start missing." print " ColdFusion not started." rval=1 fi else print "Notice: ColdFusion startup disabled in $RCFILE" rval=2 fi ;; 'stop') if [ -x $CFBIN/stop ]; then $CFBIN/stop -force fi ;; *) echo "Usage: $0 { start  stop }" rval=1 ;; esac exit $rval # 
 { start  stop }"         rval=1         ;; esac exit $rval # 

The startup and shutdown scripts in /etc/init.d generally perform both startup and shutdown functions. The startup and shutdown scripts, including the one in our example, recognize the following four arguments:

• start_msg - This is an argument passed to scripts so the that script can report a message indicating what the "start" action will do.

• stop_msg - This is an argument passed to scripts so that the script can report a message indicating what the "stop" action will do.

• start - The script will start the application.

• stop - The script will shut down the application.

You may encounter problems during boot with one of the startup programs being hung. If this is the case Ctrl ( control and pipe ) keys will normally break out of the script and continue to the next script.

All startup and shutdown scripts, including the one in the previous listing, obtain configuration data from variables in /etc/rc.config.d . Our example script checks the value of the "on/off" switch in /etc/rc.confi.d/coldfusion , which is shown in the following listing, to determine if Cold Fusion should be started:

 #  cat /etc/rc.config.d/coldfusion  # ColdFusion Application Server configuration file # CF_AUTOSTART=1  #Set to 1 to restart at boot time # 

The variable in this file is set to 1, so the application will start at the time of system boot.

Startup and shutdown scripts are run based on the directory in which a link to the script appears. Our example script should be started at run level 3 . Therefore, a link to the script appears in the directory /sbin/rc3.d , shown as the third link in the following listing:

[View full width]

 
 [View full width] 
 #  ls -l /sbin/rc3.d  total 0 lrwxr-xr-x   1 root       sys     23 Apr 26 14:32 S100nfs.server -> /sbin/init.d/nfs.  server lrwxr-xr-x    1 root        sys       19 Apr 26 14:52 S200tps.rc -> /sbin/init.d/tps.rc lrwxrwxrwx    1 root       sys      20 May 16 20:57 S790coldfusion -> ../init.d/coldfusion lrwxr-xr-x   1 root       sys     23 Apr 26 14:44 S990dtlogin.rc -> /sbin/init.d/dtlogin.rc # 

We'll get to the significance of the naming of the link shortly. For the time being, it is sufficient to know that a link called /sbin/rc3.d/S790coldfusion points to our script /init.d/coldfusion .

Applications are shut down in the opposite order from which they were started. This means that a link to the startup and shutdown script will appear in a lower-level directory for shutdown. In our example, the startup link appears in /sbin/rc3.d but the shutdown link appears in /etc/rc1.d , as shown in the following listing:

 #  ls -l /sbin/rc1.d  lrwxr-xr-x    1 root       sys         17 Apr 26 14:52 K220slsd -> /sbin/init.d/slsd lrwxr-xr-x    1 root       sys         18 Apr 26 14:45 K230audio -> /sbin/init.d/audio lrwxr-xr-x   1 root      sys       21 Apr 26 14:46 K240auditing -> /sbin/init.d/auditing lrwxr-xr-x    1 root       sys         17 Apr 26 14:43 K250envd -> /sbin/init.d/envd lrwxr-xr-x    1 root       sys         17 Apr 26 14:43 K270cron -> /sbin/init.d/cron lrwxr-xr-x    1 root       sys         15 Apr 26 14:45 K278pd -> /sbin/init.d/pd lrwxr-xr-x    1 root       sys         15 Apr 26 14:45 K280lp -> /sbin/init.d/lp lrwxr-xr-x   1 root      sys       21 Apr 26 14:49 K290hparamgr -> /sbin/init.d/hparamgr lrwxr-xr-x   1 root       sys        20 Apr 26 14:43 K290hparray -> /sbin/init.d/hparray lrwxrwxrwx   1 root      sys      20 May 16 20:57 K300coldfusion -> ../init.d/coldfusion                     .                     .                     . 

The link called /sbin/rc3.d/K300coldfusion points to our script /init.d/coldfusion . Startup for this application takes place at run level 3 and shutdown takes place at run level 1.

There is significance associated with the names of the links shown in the previous two listings. Let's take a look at the startup link in our example:

  /sbin/rc3.d/S790coldfusion  v                  script name -  coldfusion  in ex             v             sequence number - 790 in example            v           "S" for startup, "K" for shutdown         v         run level number - 3 in example 

This example is for our Cold Fusion startup script. Startup links begin with an "S" for startup . The shutdown script has a similar entry in /sbin/rc1.d , it but has a "K" as the first character of the link name to indicate kill .

Scripts are executed in lexicographical order. Gaps are left between startup scripts at a given run level and between shutdown scripts at a given run level, so when additional scripts are added, you don't have to renumber any existing scripts within a run level.

Because applications are shut down in the opposite order in which they are started, shutdown scripts do not usually have the same numbers as their startup counterparts. Two applications that start in a given order due to dependencies will usually be shut down in the opposite order in which they were started. In our example, the startup number is S790coldfusion and the shutdown number is K300coldfusion .

Scripts are run when there is a change in run level. /sbin/rc is a program that is run whenever there is a change in run level. The following listing shows /etc/inittab , which invokes /sbin/rc on the system used in our example:

[View full width]

 
 [View full width] 
 init:3:initdefault: ioin::sysinit:/sbin/ioinitrc >/dev/console 2>&1 tape::sysinit:/sbin/mtinit > /dev/console 2>&1 muxi::sysinit:/sbin/dasetup   </dev/console >/dev/console 2>&1 # mux init stty::sysinit:/sbin/stty 9600 clocal icanon echo opost onlcr ixon icrnl ignpar </dev/  systty brc1::bootwait:/sbin/bcheckrc </dev/console >/dev/console 2>&1 # fsck, etc. link::wait:/sbin/sh -c "/sbin/rm -f /dev/syscon; \                   /sbin/ln /dev/systty /dev/syscon" >/dev/console 2>&1 cprt::bootwait:/sbin/cat /etc/copyright >/dev/syscon           # legal req sqnc::wait:/sbin/rc </dev/console >/dev/console 2>&1           # system init #powf::powerwait:/sbin/powerfail >/dev/console 2>&1            # powerfail cons:123456:respawn:/usr/sbin/getty console console            # system console #ttp1:234:respawn:/usr/sbin/getty -h tty0p1 9600 #ttp2:234:respawn:/usr/sbin/getty -h tty0p2 9600 #ttp3:234:respawn:/usr/sbin/getty -h tty0p3 9600 #ttp4:234:respawn:/usr/sbin/getty -h tty0p4 9600 #ttp5:234:respawn:/usr/sbin/getty -h tty0p5 9600 #ups::respawn:rtprio 0 /usr/lbin/ups_mond -f /etc/ups_conf 

The /sbin/rc line is always present in the /etc/inittab file. There is more information about /etc/inittab coming shortly.

If you are booting your system to run level 3, then /sbin/rc will run the startup scripts present in /sbin/rc1.d , /sbin/rc2.d , and /sbin/rc3.d .

I have mentioned run levels several times in this discussion. Both the startup and shutdown scripts described here, as well as the /etc/inittab file, depend on run levels. In HP-UX 11.x, the following run levels exist:

	Halted run level.
s	Run level s, also known as single- user mode, is used to ensure that no one else is on the system so that you can proceed with system administration tasks.
1	Run level 1 starts various basic processes.
2	Run level 2 allows users to access the system. This is also known as multi-user mode.
3	Run level 3 is for exporting NFS file systems.
4	Run level 4 starts the graphical manager, including HP Common Desktop Environment (HP CDE).
5 and 6	Not currently used.

/etc/inittab is also used to define a variety of processes that will be run, and it is used by /sbin/init . The /sbin/init process ID is 1. It is the first process started on your system and it has no parent. The init process looks at /etc/inittab to determine the run level of the system.

Entries in the /etc/inittab file have the following format:

id:run state:action:process
id	The name of the entry. The id is up to four characters long and must be unique in the file. If the line in /etc/inittab is preceded by a "#", the entry is treated as a comment.
run state	Specifies the run level at which the command is executed. More than one run level can be specified. The command is executed for every run level specified.
action	Defines which of 11 actions will be taken with this process. The 11 choices for action are: initdefault , sysinit , boot , bootwait , wait , respawn , once , powerfail , powerwait , ondemand , and off .
process	The shell command to be executed if the run level and/or action field so indicates.

Here is an example of an /etc/inittab entry:

cons:123456:respawn:/usr/sbin/getty    console  console
                                       
                                       >   process
                 >   action
         >   run  state
   >   id

This is in the /etc/inittab file, as opposed to being defined as a startup script, because the console may be killed and have to be restarted whenever it dies, even if no change has occurred in run level. respawn starts a process if it does not exist and restarts the process after it dies. This entry shows all run states, since you want the console to be activated at all times.

Another example is the first line from /etc/inittab :

init:3:initdefault:

The default run level of the system is defined as 3 .

The basics of system startup and shutdown described here are important to understand. You will be starting up and shutting down your system and possibly even modifying some of the files described here. Please take a close look at the startup and shutdown files before you begin to modify them.

Now let's take a look at the commands you can issue to shut down your system.