LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Red Hat (http://www.linuxquestions.org/questions/red-hat-31/)
-   -   Kill scripts not being executed upon reboot (http://www.linuxquestions.org/questions/red-hat-31/kill-scripts-not-being-executed-upon-reboot-704261/)

druidmatrix 02-12-2009 03:27 PM

Kill scripts not being executed upon reboot
 
Hello,

I have an application that absolutely needs the kill script to run on reboot/shutdown. I have the service added to chkconfig running at runlevels 3,4 and 5. I have the necessary S and K scripts (S is 99 and K is 01) in /etc/r3.d, rc4.d and rc5.d. I also have the K01 link in /etc/rc6.d.

When I issue a `reboot` from runlevel 3, I dont see any of the K scripts executing, although the S script does run at startup. I can tell this because the first line in the init.d script is to write a line to the application log file - "starting" for start and "stopping" for stop. I see the "starting" lines, but no "stopping" lines at all unless the script is run manually with a stop argument.

I am RHEL5 release 5.1 (Tikanga). Has anyone else come across similar issues? Perhaps one of the Guru's will be kind enough to take a look?

Thanks in advance.

unSpawn 02-12-2009 04:01 PM

What does this services initscript script look like?

druidmatrix 02-12-2009 04:27 PM

Quote:

Originally Posted by unSpawn (Post 3441512)
What does this services initscript script look like?

-bash-3.1# cat /etc/init.d/impgre
#!/bin/sh
# chkconfig: 345 99 01
# description: this script starts and stops the GRE tunnel mgr
#
IMPGRE_HOME=/prod/IM/apps/impgre

case "$1" in
'start')

. ${IMPGRE_HOME}/cfg/impgre.cfg
echo -n "Starting the Tunnel Manager..." >> ${LOG_DIR}/impgremgr.log
${IMPGREMGR}/bin/impgremgr -D
;;

'stop')
. ${IMPGRE_HOME}/cfg/impgre.cfg
echo -n "Shutting down the Tunnel Manager..." >> ${LOG_DIR}/impgremgr.log
if [ -e "${IMPGREMGR}/tmp/tun_mgr.pid" ]; then
kill -INT `cat ${IMPGREMGR}/tmp/tun_mgr.pid`
else
echo "Impgremgr does not appear to be running"
fi
while [ -e "${IMPGREMGR}/tmp/tun_mgr.pid" ] ; do
sleep 1
done
;;

unSpawn 02-13-2009 01:46 AM

This initscript doesn't adhere to standards: sourcing initscript configuration should be in /etc/sysconfig/${servicename}, it doesn't use the default reporting and kill routines, and the "case" statement isn't closed (unless you didn't bother to post the whole script). What I'd do is look at default initscripts in /etc/rc.d/init.d, copy one then make it fit this service. That way you will have less things to modify, meaning less chances for making errors. If it *then* still doesn't work it would be easier to modify the script (post your "new" script) and ensure it remains consistent with the rest.

druidmatrix 02-16-2009 01:36 PM

UnSpawn,

You are absolutely right - it is not the complete script (although I think an esac would complete it) - the main thing I had tried to point out was the logging statements right at the beginning of the "start" and "stop" cases. I see both outputs in the log file if I do a manual /etc/init.d/impgre start|stop (no user environment needed). But I only see the "Starting.." statement when I do a reboot.

I am not sure what you meant by "default reporting and kill routines" - I am expecting a kill to come from the init.d script being run with "stop" by the OS during a change in runlevel. Are you saying that the application needs to be registered under /etc/services in order for the K scripts to run? In that case, why is it different for the corresponding S scripts? This bothers me....

Thanks in advance.

druidmatrix 02-16-2009 02:11 PM

One other pertinent point I should have mentioned (in light of your above response) is that the application is not added to chkconfig - I am only using the /etc/init.d/rcX.d links to the /etc/init.d/scriptname. Shouldn't that be supported?

unSpawn 02-16-2009 05:36 PM

Quote:

Originally Posted by druidmatrix (Post 3445818)
I am not sure what you meant by "default reporting and kill routines" (...) Are you saying that the application needs to be registered under /etc/services in order for the K scripts to run?

/etc/services has nothing to do with this, it's a simple, static port - servicename mapping "database" (think IANA). I mean the default routines as any initscript would use them (meaning sourced from /etc/rc.d/init.d/functions IIRC). Defaulting to available features means taking away chances for making mistakes (why invent the wheel?), and if those functions don't cover starting or stopping services properly, *then* you could expand your initscript: take a look at how for instance the sshd service implements stopping.


Quote:

Originally Posted by druidmatrix (Post 3445863)
One other pertinent point I should have mentioned (in light of your above response) is that the application is not added to chkconfig - I am only using the /etc/init.d/rcX.d links to the /etc/init.d/scriptname. Shouldn't that be supported?

Well, the /etc/init.d/rcX.d links basically are what 'chkconfig' governs. If there's a proper kill link in rc6 then this service is covered.

syg00 02-16-2009 07:00 PM

I just had a look at an old Centos server I have laying around unloved ...
Looks like it /etc/rc checks for a lock file for the "subsystem" on shutdown to see if the K??* needs to run.
Should be as simple as putting a touch for the lockfile in the start section of the script - as suggesed, just check any other (running) service script.

druidmatrix 02-17-2009 07:35 PM

UnSwpawn and Syg - both of you are absolutely right. What is needed is the /var/lock/subsys/scriptname file. Now I ask, and I am not sure this is the correct forum, can anyone confirm if this is needed for other Unix systems as well? I haven't done this on Solaris, for instance, and don't think it is needed (I haven't actually tried it with this particular app to be honest).

But thank you once again for your help.

syg00 02-17-2009 08:03 PM

Init scripts are the last place you would expect consistency.
And there isn't any - even with Linux they all do it differently (e.g. SuSE uses a different approach).


All times are GMT -5. The time now is 11:53 AM.