 |
» |
|
|
|
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 share local
file systems)
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 placeholder which HP guarantees will not be
overwritten by future releases of HP or third-party software; there
is no such placeholder, 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_productnamedaemon 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=/sample/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_productnamedaemon, we assigned our script number 900 and linked it into the /sbin/rc2.ddirectory: 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
