Hide Forgot
A recent change in glibc and shadow-utils (also in RHEL6) did add /etc/default (same as debian based distros) introducing a possible bug in detecting the correct default settings for the init script. The window is very small as we don´t document the usage of /etc/default/cman, but I don´t see a reason to take a chance. The fix is one liner to backport. > commit 27c8333b40ede1e29155774bf9cb7822c9e71f8e > Author: Fabio M. Di Nitto <fdinitto> > Date: Tue Nov 16 10:03:42 2010 +0100 > > cman init: fix NetworkManager and distro detection > > This change should finally allow Debian to use our init script almost pristine > and get the script to work on rpm based distro again. > > Signed-off-by: Fabio M. Di Nitto <fdinitto> The RHEL init script is not affected by the NM detection issue revealed upstream. I am proactively asking to have this fix in RHEL.
this is one way to verify this bug: edit /etc/sysconfig/cman and set INITLOGLEVEL=full check service cman start output (lots more output than usual) cp /etc/default/cman and set INITLOGLEVEL=quiet (one line output with cman start). This happens because /etc/default/cman is preferred over sysconfig. With the fix applied to the init script, /etc/default/cman is ignored and the output will be verbose from /etc/sysconfig/cman Here is unit testing output from engineering: - unpatched (no /etc/default/cman) [root@rhel6-node2 ~]# cat /etc/sysconfig/cman |grep INIT # INITLOGLEVEL -- select how verbose the init script should be INITLOGLEVEL=full [root@rhel6-node2 ~]# /etc/init.d/cman start Starting cluster: Checking Network Manager... [ OK ] Global setup... [ OK ] Enable Xend bridge net workaround... action not required Loading kernel modules... [ OK ] Mounting configfs... [ OK ] Starting cman... [ OK ] Starting qdiskd... [ OK ] Waiting for qdiskd to be active: 0 1 2 3 4 5 [ OK ] Waiting for quorum... [ OK ] Starting groupd... action not required Starting fenced... [ OK ] Starting dlm_controld... [ OK ] Starting gfs_controld... [ OK ] Starting ocfs2_controld... action not required Starting cmannotifyd... action not required Unfencing self... [ OK ] Joining fence domain... [ OK ] [root@rhel6-node2 ~]# /etc/init.d/cman stop Stopping cluster: [skip] [root@rhel6-node2 ~]# cp /etc/sysconfig/cman /etc/default/ [root@rhel6-node2 ~]# cat /etc/default/cman |grep INIT # INITLOGLEVEL -- select how verbose the init script should be INITLOGLEVEL=quiet [root@rhel6-node2 ~]# /etc/init.d/cman start Starting cluster: [ OK ] - patched (and /etc/default/cman available): [root@rhel6-node2 ~]# /etc/init.d/cman start Starting cluster: Checking Network Manager... [ OK ] Global setup... [ OK ] Enable Xend bridge net workaround... action not required Loading kernel modules... [ OK ] Mounting configfs... [ OK ] Starting cman... [ OK ] Starting qdiskd... [ OK ] Waiting for qdiskd to be active: 0 1 2 [ OK ] Waiting for quorum... [ OK ] Starting groupd... action not required Starting fenced... [ OK ] Starting dlm_controld... [ OK ] Starting gfs_controld... [ OK ] Starting ocfs2_controld... action not required Starting cmannotifyd... action not required Unfencing self... [ OK ] Joining fence domain... [ OK ]
Marking as verified with following remark: with this patch in RHEL the /etc/default/cman has no effect as long as /etc/sysconfig dir exists. init script snip: # rpm based distros if [ -d /etc/sysconfig ]; then [ -f /etc/rc.d/init.d/functions ] && . /etc/rc.d/init.d/functions [ -f /etc/sysconfig/cluster ] && . /etc/sysconfig/cluster [ -f /etc/sysconfig/cman ] && . /etc/sysconfig/cman [ -z "$LOCK_FILE" ] && LOCK_FILE="/var/lock/subsys/cman" fi # deb based distros if [ ! -d /etc/sysconfig ]; then [ -f /etc/default/cluster ] && . /etc/default/cluster [ -f /etc/default/cman ] && . /etc/default/cman [ -z "$LOCK_FILE" ] && LOCK_FILE="/var/lock/cman" type chkconfig > /dev/null 2>&1 || alias chkconfig=local_chkconfig fi cman-3.0.12-41.el6.x86_64
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0537.html