Re: [cobalt-developers] Qube3 orderly shutdown and reboot processes

[Malcolm McLeary <mmcleary@xxxxxxx>]

Hi Guys,

on 27/10/01 8:08 PM, Malcolm McLeary at mmcleary@xxxxxxx wrote:

> I have installed FileMaker Server for Linux on my Qube3 and it is doing the
> serving thing fine, but shutdown is a problem.
> 
> The instructions say to use;
> 
> # chkconfig fmserverd on
> 
> to enable correct startup and shutdown of FileMaker Server, but as far as I
> can determine "chkconfig" is part of Red Hat Linux 6.2 and hence not on the
> Qube3.
> 
> At the moment a shutdown terminates fmserverd without alerting clients and
> without closing the database tables ... not good.

Further to my post of last night, I believe I have the makings of a work
around to my shutdown/reboot problem.

The specs for FileMaker Server for Linux says Red Hat 6.1 or 7.0 ... the
version of Linux running on Sun/Cobalt Appliance is based on Red Hat 6.x but
I'm not sure what that really means.  What I have established is that
chkconfig is not there and I believe it is part of Red Hat 6.2.  I found a
reference at <http://www.linux.org/apps/AppId_69.html> which says;

> chkconfig is a tool to simplify management of the symbolic links in /etc/rc.d
> under Linux. This version is based on the latest release of chkconfig from
> RedHat-6.2, adding an autoconf-style configure script to simplify porting to
> other distributions/platforms.

So I can get the source, I can compile it, and I can install it, but ...
this is getting a bit deep for me.  I use Cobalt Appliances because all the
"hard" work of setting up and managing a Linux server is already done.

FileMaker Server is driven from the command line where as the rest of Qube3
management is driven from a Web interface, but I'm working on building a
Qube3 install and GUI package as a practical exercise.

However the question remains ... what does chkconfig really do?

I get the feeling that it just simplifies the management of the symbolic
links in /etc/rc.d.  However I have already established that they are there
in my system even though chkconfig isn't.  So whats missing?

My conclusion last night was that as there wasn't an entry in
/var/lock/subsys for fmserverd, the k files for the halt and reboot
runlevels were not being executed.

To test this theory this morning I "touched" fmserverd in /var/lock/subsys
(thus creating an entry) and asked the system to reboot.

This time /var/log/fmserver/events.log indicates that;

Oct 28 10:24:22 blue.local INFO: Asked to quit...

and on restart I did not get a bunch of "not closed properly" messages.

So I believe /etc/rc.d/init.d/fmserverd needs to be modified to "touch"
/var/lock/subsys/fmserverd when it starts fmserverd.  Hence the modified bit
looks like this;

start()
{
        echo -n "Starting fmserverd: "
        ${fmserverd} ${start_args}
        RETVAL=$?
        if [ $RETVAL = 0 ]; then
                touch /var/lock/subsys/fmserverd
                echo_success
        else
                echo_failure
        fi
        echo
        return $RETVAL
}

So is this a an oversight in the shipping version of
/etc/rc.d/init.d/fmserverd or is this something chkconfig deals with after
the;

# chkconfig fmserverd on

command is issued?

Is there a .pkg for chkconfig for the Qube3 and would it resolve this issue?

Cheers,  Malcolm

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

                       Information Alchemy Pty Ltd
                             ACN 089 239 305
                           Canberra, Australia

Malcolm McLeary                                Mobile:     0412 636 086
Managing Director                              Email:  mmcleary@xxxxxxx

     This message was sent using Outlook Express 5.0 for Macintosh.