Red Hat Bugzilla – Bug 129933
GFS service should not be started by default
Last modified: 2014-09-08 20:40:43 EDT
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):
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
Starting lock_gulmd: Starting lock_gulmd: 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
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:
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
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
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
+ # Make sure that ccsd is running
+ ccs_read list 2>/dev/null > /dev/null || exit 0
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
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.