Hi Guys, on 27/10/01 8:08 PM, Malcolm McLeary at [EMAIL PROTECTED] 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: [EMAIL PROTECTED] This message was sent using Outlook Express 5.0 for Macintosh. _______________________________________________ cobalt-developers mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-developers
