Bug 130827 - gulm_tool forceexpire can expire already expired nodes
gulm_tool forceexpire can expire already expired nodes
Status: CLOSED CURRENTRELEASE
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Brian Stevens
GFS Bugs
:
Depends On:
Blocks: 137219
  Show dependency treegraph
 
Reported: 2004-08-24 18:38 EDT by Adam "mantis" Manthei
Modified: 2014-09-08 20:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-29 17:49:02 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)
adds node state check to Force_Node_Expire(char *name) (554 bytes, text/plain)
2004-08-24 18:42 EDT, Adam "mantis" Manthei
no flags Details

  None (edit)
Description Adam "mantis" Manthei 2004-08-24 18:38:38 EDT
Description of problem:
gulm_tool forceexpire can expire already expired nodes.  The result of
which is that the master lock_guld core will attempt to fence
everytime that force expired is called.  This can cause the master
server to get bogged down with fencing actions.

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

How reproducible:
Always

Steps to Reproduce:
1. start lock_gulmd on a slave or client node
2. modify ccsd so that the fencing action never returns success 
   (agent = "false")
3. run `gulm_tool forceexpire $master $node` multiple times
4. run `ps` on the master node, there should now be mulitple
   fence_node processes all trying to fence node $node.
Comment 1 Adam "mantis" Manthei 2004-08-24 18:42:42 EDT
Created attachment 103043 [details]
adds node state check to Force_Node_Expire(char *name)

This patch will verify that the the node that is being marked expired is in the
logged in state.  If it is already in the logged in state, there isn't much
point in calling fence_node again since fence_node is already in the process of
being called, or has failed.  If the node is not in the logged in state, 1008
(Bad state change) is returned.  The error code should probably differ from the
case that the node is not logged in (1007)
Comment 2 michael conrad tadpol tilstra 2004-08-30 11:36:28 EDT
this looks ok.  I'm either way on the error codes.  If you think it
would be clearer with two differnt ones, lets do that.
Comment 3 michael conrad tadpol tilstra 2004-08-30 12:43:34 EDT
patch applied.
Comment 6 Lon Hohberger 2010-10-29 17:49:02 EDT
This bugzilla is reported to have been fixed years ago.

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