Bug 227232 - Services are starting after machine reboot (rgmanager restart)
Services are starting after machine reboot (rgmanager restart)
Status: CLOSED WONTFIX
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: rgmanager (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Cluster QE
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-03 14:47 EST by Tomasz Jaszowski
Modified: 2009-04-16 16:21 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-29 14:34:20 EDT
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 Tomasz Jaszowski 2007-02-03 14:47:04 EST
Description of problem:
I don't want anything to start automaticly, so I've turned off automatic start
of cluster during boot and not checked autostart on any cluster services.

Problem: when services are enabled and started, after restart of rgmanager (and
after reboot or power cycle and manual start of cluster software), cluster
services are starting (if they wasn't disabled...)

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. create 2node cluster (propably doesn't matter, but i was checking on 2node)
2. create fence domain with only one node
3. create service with action restart and set fence domain created at 2.
4. enable service
4. stop start rgmanager or power cycle node with started service
  
Actual results:
cman,ccsd,fenced,rgmanager started
service enabled and started (by clusvcadm -e)
service rgmanager stop/start (or powercycle/reboot and cman, ccsd, fenced,
rgmanager start)
services are starting

Expected results:
cman,ccsd,fenced,rgmanager started
service enabled and started (by clusvcadm -e)
service rgmanager stop/start (or powercycle/reboot and cman, ccsd, fenced,
rgmanager start)
services are not starting (unless they have autostart option set)

after i'll check if machine, data and other are ok i would like start them using
clusvcadm -e

Additional info:
Comment 1 Lon Hohberger 2007-02-05 13:09:30 EST
What rgmanager package do you have?
Comment 2 Tomasz Jaszowski 2007-02-06 06:14:52 EST
- rgmanager-1.9.54-1
Comment 3 Lon Hohberger 2007-02-09 15:31:00 EST
Ok, so, in your test case, you are never rebooting the other node, or shutting
rgmanager down, right...

If this is the case, then what you are seeing is correct/expected behavior.  The
other node has the state recorded as 'stopped'.  Whenever a membership
transition occurs, services are evaluated to see if the a node (presumably the
new node) is capable of running any service in the 'stopped' state.  If so, then
the service is started.

'Autostart' is for cluster quorum transitions, or total rgmanager group
transitions.  Since the surviving node maintains the cluster quorum (and
rgmanager is still running), the "enabled" vs "disabled" state is not reset.

What we can do is provide an option to disable a service at the point no nodes
are capable of running it.  For example, in your case, only one node is capable
of running the service.  When it is offline (or rgmanager is down), the other
node could then mark the service as 'disabled' automatically - because it knows
that:

 (a) No nodes are capable of running the service, and
 (b) the administrator wants the service disabled if (a) occurs.

Comment 5 Lon Hohberger 2007-07-31 14:33:46 EDT
Note that rgmanager does stop-before-start - so your stop scripts should be able
to clean up any problems that exist prior to the service starting.  If that's
not the case (and you want manual intervention prior to service start), you can
disable rgmanager on boot:

   chkconfig --del rgmanager
Comment 6 Lon Hohberger 2008-07-29 14:33:32 EDT
Need to reopen this momentarily for housekeeping

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