Bug 410361

Summary: fence_xvmd will never be started by the cman init script
Product: Red Hat Enterprise Linux 5 Reporter: Johannes Russek <johannes.russek>
Component: cmanAssignee: Lon Hohberger <lhh>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: low Docs Contact:
Priority: low    
Version: 5.1CC: casmith, cluster-maint, pcfe
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0347 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 15:58:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Remove bad dom0 check. none

Description Johannes Russek 2007-12-04 13:24:31 UTC 
Description of problem:
configuring fence_xvmd in the cluster wide configuration will never lead to cman
starting fence_xvmd because the init script checks for a running xend, which
will always fail as the cman init script is started way earlier than cman.


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

any (of my knowledge are the packages that come with RHEL 5u0 and 5u1)


How reproducible:

very :)

Steps to Reproduce:

configure <fence_xvmd/> in the cluster.conf, reboot a node.
  
Additional info:

here is my last mail including Lons most recent answer:

Lon Hohberger schrieb:
> For now, just put fence_xvmd in /etc/rc.d/rc.local
>
> File a bug against cman and assign it to me.  It fell off my radar.  It
> looks like basically, we should -
>
> * start fence_xvmd if enabled in the config (don't do the xm list check)
>
> * fence_xvmd should wait (maybe for some timeout - 5 minutes?  10
> minutes?) for xend to come up, and die if it doesn't start (so as to not
> keep running for no reason).
>   
why would it need a timeout to die? apparently, if someone put that into 
his cluster config it should be running wether xend comes up or not, 
maybe throw a warning. what if xend doesn't come up for a reason but a 
manual fix corrected that and then comes up but after fence_xvmds 
timeout. you'd have to either manually start fence_xvmd or restart cman, 
wouldn't you?
i think if it's configured it should just start. it would be smart to 
have it warn about missing xend every so minutes or sthg like that, 
though :)
regards,
johannes
Comment 1 Lon Hohberger 2007-12-04 15:07:23 UTC 
> In 5.1, it seems to work even if xend hasn't started yet.
> 
> It just sits there and does nothing until xend comes up - but it works.

Joining multicast group
ipv4_recv_sk: success, fd = 7
virConnectOpen: Connection refused
My Node ID = 1
NOTICE: virConnectOpen(): Connection refused; cannot fence!
NOTICE: virConnectOpen(): Connection refused; cannot fence!
NOTICE: virConnectOpen(): Connection refused; cannot fence!
NOTICE: virConnectOpen(): Connection refused; cannot fence!
NOTICE: virConnectOpen(): Connection refused; cannot fence!
...
repeats.
(service xend start on another console)
...
Domain                   UUID                                 Owner
State
------                   ----                                 -----
-----
Domain-0                 00000000-0000-0000-0000-000000000000 00001
00001
frederick                ef84f5cf-8589-41f6-8728-ac5170c42cbc 00001
00002
molly                    d1cf68a4-0bdf-5a88-81a7-5c41976147f6 00001
00002
Storing frederick
Storing molly

Sorry for the confusion.
Comment 2 Lon Hohberger 2007-12-04 15:07:48 UTC 
oh my fault - it's just the dom0 check
Comment 3 Lon Hohberger 2007-12-04 15:10:46 UTC 
Created attachment 277061 [details]
Remove bad dom0 check.
Comment 4 Lon Hohberger 2007-12-04 15:13:14 UTC 
Workaround:

* Put fence_xvmd in /etc/rc.d/rc.local
* Comment out line #192 (the domain-0 check) in /etc/init.d/cman
Comment 5 RHEL Program Management 2007-12-04 15:14:27 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 8 errata-xmlrpc 2008-05-21 15:58:32 UTC 
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 the 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-2008-0347.html