init.d shutdown problem (h e l p . . .)

Pete Nesbitt pete at linux1.ca
Fri Apr 23 01:45:18 UTC 2004


On April 22, 2004 12:07 pm, Dave Iler wrote:
> I've been working on this for three of four days and I'm reaching the
> end of my rope.
>
> I have a script that I created in /etc/init.d that is managed by
> chkconfig.  It will properly startup up an Oracle database when the
> machine boots, but it does not execute to stop when moving to runlevels
> [016].
>
> My understanding is that when Linux moves to a new run level that it
> first executes all of the K scripts in the appropriate rc?.d directory
> for the new run level, then it executes all of the S scripts in that
> directory.  Yes, I know they are actually links to scripts in the
> /etc/init.d directory.
>
> /etc/init.d/suuce10
>
> It works fine from the command line.
>     /etc/init.d/suuce10 start
>     /etc/init.d/suuce10 stop
>
> This works too, all without error.
>     service suuce10 start
>     service suuce10 stop
>
> I have a link (/etc/rc1.d/K05suuce10).  This works without complaint.
>     /etc/rc1.d/K05suuce10 start
>     /etc/rc1.d/K05suuce10 stop
>
> When I do an "init 1" the system goes into single user mode.  A "ps -ef
>
> | grep '[o]ra_smon'" shows that the Oracle instance is still running.
>
> So too is the listener.  No, there is no /ect/rc1.d/S??suuce10.  So my
> /etc/rc1.K05suuce10 script did NOT execute on the way down to single
> user mode.  X-windows stopped fine.
>
> suuce10 shows up in the service configuration gui, and is checked.
>
> I am running Redhat Enterprise 3 AS, Update 1, with all the latest patches.
>
> It is running on a Dell Optiplex G-270 with 2GB of RAM and (2) 120GB
> SATA disk drives.
>
> /etc/init.d/suuce10 is owned by root.root.  Protection is 755.
>
> My frequently modified script looks like this, chkconfig listing follows
> it:
>
> #!/bin/bash
> #
> # chkconfig: 35 99 05
> # description: SUU startup.
> #
>
> PATH=/sbin:/usr/sbin:$PATH
> RETVAL=0
>
>
> prog=suuce10
>
>
> # Source function library.
> . /etc/rc.d/init.d/functions
>
> usage ()
> {
>         echo "Usage: service $prog {start|stop|restart}"
> }
>
>
> start ()
> {
>         if ps -fU oracle | grep '[o]ra_smon_CEcms' > /dev/null; then
>                 exit
>         fi
>
>         echo -n $"Starting suuce10: "
>
>         su - oracle -c '/home/oracle/bin/cecms start'
>         su - oracle -c '/home/oracle/bin/oralistener start'
> }
>
> stop ()
> {
>         if ! ps -fU oracle | grep '[o]ra_smon_CEcms' > /dev/null; then
>                 exit
>         fi
>
>         echo -n $"Stopping suuce10: "
>
>         su - oracle -c '/home/oracle/bin/cecms stop'
>         su - oracle -c '/home/oracle/bin/oralistener stop'
> }
>
> restart ()
> {
>     stop
>     start
> }
>
>
> case "$1" in
>     start)
>         start
>         ;;
>     stop)
>         stop
>         ;;
>     *)
>         usage
>         ;;
> esac
>
> exit
>
>
> Here's my chkconfig listing:
>
> [root at nomad init.d]#
> [root at nomad init.d]# chkconfig --list suuce10
>
> suuce10         0:off   1:off   2:off   3:on    4:off   5:on    6:off


Hi Dave,
Everything looks ok. I would try redirecting the output to a file instead of 
to null. There may be a hint in the output. 

The only other thing I can think of is that at work they (I don't touch 
oracle) try to stop the db before a shutdown or reboot because the system 
(Solaris) does not give it enough time to kill oracle properly. Could there 
be something similar going on here? Are there oracle logs you can check?

-- 
Pete Nesbitt, rhce





More information about the redhat-list mailing list