Bug 452234 - Preventing cluster services to run at boot
Preventing cluster services to run at boot
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: cluster (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Fabio Massimo Di Nitto
Cluster QE
: FutureFeature
Depends On:
Blocks: 563901 667650 667652
  Show dependency treegraph
 
Reported: 2008-06-20 09:19 EDT by Federico Simoncelli
Modified: 2011-01-06 06:06 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 563901 (view as bug list)
Environment:
Last Closed: 2011-01-06 06:05:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Federico Simoncelli 2008-06-20 09:19:13 EDT
Description of problem:

A different boot sequence is needed to safely power up a fenced node and
therefore skipping the cluster services to avoid problems such as long waits and
fences in a two-nodes configuration.
A solution could involve setting a boot parameter (eg: nocluster) to prevent
cman/gfs/rgmanager to start automatically.

References:
https://www.redhat.com/archives/linux-cluster/2008-June/msg00143.html
https://www.redhat.com/archives/linux-cluster/2008-June/msg00158.html

The check could be accomplished with few lines of code inside man/gfs/rgmanager
init files, eg:

if strstr "$( cat /proc/cmdline )" "nocluster"; then
  # ...
  exit 0;
fi

This solution will also make impossible to start the services manually later on,
is there a way to remove this side effect?
Comment 1 Lon Hohberger 2008-06-24 13:09:03 EDT
Various things come to mind --

  Check the runlevel/previous runlevel
  Check the ppid of the script (maybe it's /sbin/init during boot)?
Comment 2 Fabio Massimo Di Nitto 2008-06-27 04:10:12 EDT
We can also use the approach of touching a file, but for sure not in /etc. It
has to be somewhere like /tmp and we need to make sure we can actually do it,
otherwise we are back at the original problem.
Comment 3 Fabio Massimo Di Nitto 2009-05-04 23:49:10 EDT
Federico,

did you ever have time to propose a patch for this bug?

This is what we agreed last on the mailing list I believe.

Thanks
Fabio
Comment 4 Fabio Massimo Di Nitto 2010-02-11 09:03:47 EST
For the record: another approach could use a duet-init-script sequence.

cman-bootcheck -> parses /proc/cmdline and touch/not touch a file

cman checks for that file and warn.

user can remove the file and start cman even after boot as cman-bootcheck will never run again.

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