 |
» |
|
|
|
This section explains how to make applications and services
start automatically on boot and stop on shutdown. To automate starting and stopping a subsystem you need to
do all of the following: Decide at what run level(s) you want the subsystem to start
and stop. Typically, subsystems get stopped at one run level lower than
the one they were started in, so a subsystem started at run level
3 will be stopped at run level 2. You will probably want to start
your subsystem at level 1, 2 or 3. Generally, these run levels perform the following functions: - Run level 1:
minimal system configuration - Run level 2:
multi-user services, except NFS server - Run level 3:
NFS server (to export local file systems)
For
details, see the HP-UX 10.0 File System Layout White
Paper on http://docs.hp.com. To see exactly what is being started on your system at each
run level, look at /sbin/rcn.d/S*, where n is the run level. Unless your subsystem depends on NFS-export services such
as rpc.mountd and nfsd, run level 2 is a good place to start it. Run level 2 is a safe, as well as usually a logical, choice
because it has a place-holder which HP guarantees will not be overwritten
by future releases of HP or third-party software; there is no such place-holder,
and hence no such guarantee, at the other run levels. Write a script to start and stop the subsystem,
and an accompanying configuration script to tell the boot process
whether or not this script should be run. Use the template /sbin/init.d/template; see the example below. Create symbolic links that will cause your script
to be run at the right place in the boot and shutdown sequences. See the example below. Reboot the system to make sure everything works. On a busy system, this may be inconvenient, but beware of
testing on a configuration other than the one on which your subsystem
will actually run; any differences in start-up/shutdown configuration between
the test system and the production system may invalidate the test.
Example:This example shows
one way to automate the start-up of a server daemon, called web_productname_daemon: Decide on run level: See what’s started at run level 2: ls /sbin/rc2.d/S*
/sbin/rc2.d/S008net.sd
/sbin/rc2.d/S560SnmpMaster
/sbin/rc2.d/S100swagentd
/sbin/rc2.d/S565SnmpHpunix... |
See what’s started at run level 3: ls /sbin/rc3.d/S*
/sbin/rc3.d/S100nfs.server |
/sbin/rc3.d/S100nfs.server is a link to /sbin/init.d/nfs.server, which starts up portmap, rpc.mountd, nfsd and related functions. Since none of these are needed
by the web_productname daemon, it is safe to start it in run level 2, using the
placeholder number 900 (see below). Similarly, we stop the script in run level 1, using the placeholder number
100.
Write the start-up/shutdown and configuration scripts. You can use /sbin/init.d/template as a basis, and create the following start-up/shutdown
script, saving it as /sbin/init.d/web_productname: |
#!/sbin/sh
PATH=/usr/sbin:/usr/bin:/sbin
export PATH
web_productname_daemon="web_productname"
rval=0
killproc()
{
pid=`ps -e | awk '$NF~/'"$1"'/ {print $1}'`
if [ "X$pid" != "X" ]
then
if kill "$pid"
then
echo "$1 stopped"
else
rval=1
echo "Unable to stop $1"
fi
fi
}
case $1 in
'start_msg')
# message that appears in the startup checklist
echo "Starting the web_productname daemon"
;;
'stop_msg')
# message that appears in the shutdown checklist
echo "Stopping the web_productname daemon"
;;
'start')
# source the configuration file
if [ -f /etc/rc.config.d/web_productname]
then
. /etc/rc.config.d/web_productname
else
echo "ERROR: /etc/rc.config.d/web_productname MISSING"
fi
# Check to see if the web_productname daemon exists,
# is executable and should be started
if [ "$WEB_PRODUCTNAME" -eq 1 -a -x
"$WEB_PRODUCTNAMEHOME/$web_productname_daemon" ]
then
cd $WEB_PRODUCTNAMEHOME
./$web_productname_daemon
print "$web_productname_daemon started"
else
print "failed to start $web_productname_daemon"
rval=2
fi
;;
'stop')
killproc $web_productname_daemon
;;
*)
echo "usage: $0 {start|stop|start_msg|stop_msg}"
rval=1
;;
esac
exit $rval |
|
Then create a configuration file, /etc/rc.config.d/web_productname, to tell the above script where to find the web_productname daemon and whether or not to start it up (1=yes; 0=no): #!/sbin/sh#
# v1.0 web_productname startup/kill config
# WEB_PRODUCTNAME: Set to 1 to start
# web_productname_daemon
# WEB_PRODUCTNAMEHOME: home dir for web_productname
WEB_PRODUCTNAME=1
WEB_PRODUCTNAMEHOME=/msw/web_productname/binhp |
| | | |  | NOTE: Setting the start-up variable (WEB_PRODUCTNAME in
this case) to 0, rather than deleting the script, is the way to
remove a subsystem from the start-up sequence. This is particularly
important in the case of HP and third-party scripts; do not edit
them, delete them or move them; simply change the variable in the
appropriate script under /etc/rc.config.d/ to 0 if you don’t want the corresponding start-up
script to run. | | | | |
Create symbolic links that cause the script to be run
at the right
place in the boot and shutdown sequences. Since HP guarantees that scripts using the number 900 in run
level 2 will not be overwritten when we upgrade the system or add
HP or third-party software, and run level 2 is a good place to start
the web_productname daemon, we assigned our script number 900 and linked
it into the /sbin/rc2.d directory: ln -s /sbin/init.d/web_productname /sbin/rc2.d/S900web_productname
The S indicates “start” and the 900 determines
starting order within
the run level, so our script starts
late (currently last) in run level 2. Similarly, HP guarantees scripts using the number 100 in run
level 1 will not be overwritten, so we also assigned our script
the number 100 and linked it into the /sbin/rc1.d directory, this time with a K (for “kill”) code
letter: ln -s /sbin/init.d/web_productname /sbin/rc1.d/K100web_productname
|
This means that the web_productname daemon is stopped after most other functions in run
level 1 as the system shuts down. Test the script itself, and test that it works correctly
in the start-up and shutdown processes. Run /sbin/init.d/web_productname several times “by hand” to debug it, then
install it (as described in step 3 above) on a test system which you
re-booted to test that the daemon was started and stopped correctly, then
finally install it on the production system and reboot that system.
|
Printable version
