Bug 133258 – fence_tool should exit non-zero on all failures

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 133258 - fence_tool should exit non-zero on all failures

Summary:	fence_tool should exit non-zero on all failures

Status:	CLOSED WONTFIX

Aliases:	None

Product:	Red Hat Cluster Suite
Classification:	Red Hat
Component:	gfs (Show other bugs)
Sub Component:
Version:	4
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	David Teigland
QA Contact:	GFS Bugs
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2004-09-22 15:35 EDT by Derek Anderson
Modified:	2010-01-11 21:58 EST (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-01-04 22:23:59 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)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Derek Anderson 2004-09-22 15:35:39 EDT

Description of problem:
Similar to bug #132989, but for the fence_tool.

I'm in a state where a fence operation is failing, so the fence domain
service is in the "recover" state.  Attempt to do a "fence_tool leave"
in this state is not going to work (and doesn't, which is fine). 
However, the tool returns zero and reports no error.

[root@tng3-1 cluster]# cat /proc/cluster/services
Service          Name                              GID LID State     Code
Fence Domain:    "default"                           1   2 recover 2 -
[1 4 2 5]

[root@tng3-1 cluster]# fence_tool leave
[root@tng3-1 cluster]# echo $?
0
[root@tng3-1 cluster]# cat /proc/cluster/services
Service          Name                              GID LID State     Code
Fence Domain:    "default"                           1   2 recover 2 -
[1 4 2 5]

[root@tng3-1 cluster]#

Version-Release number of selected component (if applicable):
[root@tng3-1 cluster]# fence_tool -V
fence_tool DEVEL.1095793252 (built Sep 21 2004 14:03:23)
Copyright (C) Red Hat, Inc.  2004  All rights reserved.

How reproducible:
Yes.


Steps to Reproduce:
1. Put the fence domain service in 'recover' state
2. Run 'fence_tool leave'
3.
  
Actual results:
Return code 0, no error reported.

Expected results:
Non-0 return code. Error reported.

Additional info:

Comment 1 David Teigland 2004-09-23 03:43:19 EDT

fence_tool leave just does kill(pid, SIGTERM).  I can't think
of a nice way off hand to check if fenced exits or not.  I
believe it /will/ exit in response to the delivered signal
once it's done with recovery.  In that sense, it's successful
even if fenced doesn't exit immediately.  Will think about this
a bit more, any ideas are welcome.

Comment 2 Jonathan Earl Brassow 2004-09-24 09:39:28 EDT

Same issue as ccs_update...

Is there some sort of ping you could give the fence daemon that responds by 
saying "aliving" or "shuting down"?  Perhaps this is over-engineering the 
problem...

Comment 3 Kiersten (Kerri) Anderson 2004-11-16 14:08:48 EST

Updating version to the right level in the defects.  Sorry for the storm.

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