This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 129933 - GFS service should not be started by default
GFS service should not be started by default
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Brian Stevens
GFS Bugs
Depends On:
Blocks: 137219
  Show dependency treegraph
Reported: 2004-08-14 13:53 EDT by Jos Vos
Modified: 2014-09-08 20:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-10-29 17:49:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for removing the default runlevels. (1.28 KB, patch)
2004-08-14 13:55 EDT, Jos Vos
no flags Details | Diff
don't start lock_gulmd if ccsd is not running (336 bytes, text/plain)
2004-08-16 14:43 EDT, Adam "mantis" Manthei
no flags Details

  None (edit)
Description Jos Vos 2004-08-14 13:53:39 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):

Additional info:
I will submit the patch I made to solve this.
Comment 1 Jos Vos 2004-08-14 13:55:30 EDT
Created attachment 102733 [details]
Patch for removing the default runlevels.
Comment 2 Adam "mantis" Manthei 2004-08-16 11:44:58 EDT
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

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:
                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.
Comment 3 Jos Vos 2004-08-16 13:37:54 EDT
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.
Comment 4 Adam "mantis" Manthei 2004-08-16 14:41:07 EDT
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...
Comment 5 Adam "mantis" Manthei 2004-08-16 14:43:21 EDT
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
Comment 6 Adam "mantis" Manthei 2004-08-16 14:57:56 EDT
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
Comment 7 Adam "mantis" Manthei 2004-09-14 11:13:02 EDT
The lock_gulmd patch has been committed.  I think that this should be
good enough to resolve this complaint.
Comment 10 Lon Hohberger 2010-10-29 17:49:06 EDT
This bugzilla is reported to have been fixed years ago.

Note You need to log in before you can comment on or make changes to this bug.