Description of problem: When GFS is installed, all related services are started by default, although they are not (yet) configured. This causes all kinds of errors. It would be better to have no default runlevels in the chkconfig line of the init scripts Version-Release number of selected component (if applicable): 6.0.0-7.1 Additional info: I will submit the patch I made to solve this.
Created attachment 102733 [details] Patch for removing the default runlevels.
Technically speaking you are correct. The man page for chkconfig states: If the service should not, by default, be started in any runlevels, a - should be used in place of the runlevels list. The error messages that are generated are rather few however... From the console: Starting ccsd: Starting ccsd:CCS_ARCHIVE not specified in /etc/sysconfig/gfs FAILED Starting lock_gulmd: Starting lock_gulmd: FAILED FAILED From the syslog: Aug 16 10:29:19 trin-09 ccsd: Starting ccsd: Aug 16 10:29:19 trin-09 ccsd: CCS_ARCHIVE not specified in /etc/sysconfig/gfs Aug 16 10:29:19 trin-09 rc: Starting ccsd: failed Aug 16 10:29:19 trin-09 lock_gulmd: Starting lock_gulmd: Aug 16 10:29:20 trin-09 lock_gulmd: Failed to get "cluster.ccs" from ccsd: -22:22:Invalid argument Aug 16 10:29:20 trin-09 lock_gulmd: In main_main.c:260 (v6.0.0) death by: Errors parsing configuration from ccs: Invalid argument Aug 16 10:29:20 trin-09 lock_gulmd: failed Aug 16 10:29:20 trin-09 lock_gulmd: Applying the provided patch also means changing documentation (manuals, training labs, etc.) which seems like a lot of extra work for a few harmless (yet annoying) error messages on startup of an unconfigured system. I can eliminate all of the lock_gulmd messages by putting a runtime dependency on CCS in the scripts, so that should at least clean things up a little more.
Another (even better) solution would be to let the GFS init scripts check some basic things to see if the service is actually configured and otherwise not proceed at all (like some scripts check the existance of a config file for its own service and otherwise exit without starting (or stopping) anything). Then it can stay as it is now, only the init scripts contain a few extra checks.
which is pretty much what I just said... The GFS init script CURRENTLY requires that an entry be in /etc/fstab for it to mount a GFS filesystem. If there is no entry in /etc/fstab for GFS, the init script doesn't do anything but load a couple kernel modules. The pool init script CURRENTLY requires nothing for configuring. It will try to detect pools on the system and assemble whatever it can. If there are no pools discovered, it will not produce any errors. The only side effect is that there is an extra kernel module loaded. lock_gulmd requires that ccs be running. I'm going to add a check to the lock_gulmd script not to execute if there is not a running ccsd service (i.e. "putting a runtime dependency on CCS"). This eliminates "all kinds of errors" that you originally complained about. That leaves the ccsd init script. It will try to autodetect a ccs archive (i.e. an already configured cluster) If it does not find an archive, it will a single error message and fail to start. I don't see the value in disabling this service by default in the init scripts simply to eliminate one extra line of output on system startup. I will post the patch that adds the ccsd dependency to lock_gulmd...
Created attachment 102771 [details] don't start lock_gulmd if ccsd is not running --- lock_gulmd.orig 2004-08-16 13:41:11.272213613 -0500 +++ lock_gulmd 2004-08-16 13:40:49.436034621 -0500 @@ -70,6 +70,9 @@ # See how we were called. case "$1" in start) + # Make sure that ccsd is running + ccs_read list 2>/dev/null > /dev/null || exit 0 + start rtrn=$?
I should have looked at the gfs init script *before* posting that last comment. If gfs is not listed in /etc/fstab, it won't even load the modules.
The lock_gulmd patch has been committed. I think that this should be good enough to resolve this complaint.
This bugzilla is reported to have been fixed years ago.