Bug 437867 - Fence storm with fence_egenera
Fence storm with fence_egenera
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: fence (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Jim Parsons
Cluster QE
: ZStream
Depends On:
Blocks: 459501
  Show dependency treegraph
Reported: 2008-03-17 15:59 EDT by Bryn M. Reeves
Modified: 2016-04-26 19:26 EDT (History)
9 users (show)

See Also:
Fixed In Version: fence-1.32.65-1.el4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-10 12:31:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test boot watch patch (954 bytes, text/html)
2008-08-11 14:29 EDT, Jason Willeford
no flags Details

  None (edit)
Description Bryn M. Reeves 2008-03-17 15:59:07 EDT
Description of problem:
When initiating a manual fencing operation from one blade in an Egenera frame,
the node carrying out the fencing considers its fencing operation to have failed
and becomes stuck in a loop repeatedly trying to fence the target node.

In fact, the target has been successfully fenced and is repeatedly interrupted
during bootup by the subsequent retries from the fencing node.

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

How reproducible:

Steps to Reproduce:
1. Manually initiate fencing from one node.
Actual results:
Fencing node continually reports that fencing has failed & re-attempts the
operation. Target node never gets to complete booting.

Expected results:
The first successful fence operation is correctly recognised by the fencing node
and is not re-tried forever.

Additional info:
Comment 1 RHEL Product and Program Management 2008-03-17 16:08:29 EDT
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
Comment 11 Jason Willeford 2008-03-24 12:02:15 EDT
Once a patch has been provided, the customer has agreed to test.
Comment 16 Jim Parsons 2008-04-02 11:54:34 EDT
Oh, nevermind! Above comment says they will test for us ;)
Comment 18 Kiersten (Kerri) Anderson 2008-05-07 12:14:17 EDT
Moving this out to 4.8, and we need a way to reproduce this issue.
Comment 31 Issue Tracker 2008-08-08 11:35:06 EDT
As we know, the egenera has redundant control blades that can power on/off
the individual blades. The cluster configuration here has been configured
to fence a machine twice, once from each cblade. This is creating a race
condition between fence_egenera script on each one. There are two
solutions to this the way that I see it. 

1. Fix configuration to fence from the second control blade only if the
attempted fence failed on the first control blade. 

2. Fix issue in fence_egenera that causes race condition in the first
place. It appears that the script does not understand what to do with the
"Booting" status, so it reboots the node. This can be fixed by either
waiting until the "Booting" status changes to something that it recognizes
or just go ahead and force a reboot in the "Booting" stage. In either case
it must return success at the end to prevent the current condition.

This event sent from IssueTracker by calvin_g_smith 
 issue 164929
Comment 32 Issue Tracker 2008-08-08 18:31:53 EDT
Attached is a patch for the fence_egenera script that recognizes if the
machine is already booting up and returns success if that is the case. 

This event sent from IssueTracker by calvin_g_smith 
 issue 164929
it_file 147843
Comment 33 Jason Willeford 2008-08-11 14:29:59 EDT
Created attachment 313993 [details]
test boot watch patch
Comment 35 Chris Feist 2009-06-10 12:31:08 EDT
This is fixed in RHEL4.8 in fence-1.32.65-1.el4 and beyond.

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