From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11174 invoked by alias); 23 Jul 2008 18:26:46 -0000 Received: (qmail 11138 invoked by uid 9453); 23 Jul 2008 18:26:46 -0000 Date: Wed, 23 Jul 2008 18:26:00 -0000 Message-ID: <20080723182646.11122.qmail@sourceware.org> From: teigland@sourceware.org To: cluster-cvs@sources.redhat.com, cluster-devel@redhat.com Subject: Cluster Project branch, STABLE2, updated. cluster-2.03.05-10-gff93465 X-Git-Refname: refs/heads/STABLE2 X-Git-Reftype: branch X-Git-Oldrev: 8819aeb2ea8d74c23c4af717bec8d55f8fcdb263 X-Git-Newrev: ff934655dbb265150c7c9ae5e499645be26ab586 Mailing-List: contact cluster-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: cluster-cvs-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00126.txt.bz2 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Cluster Project". http://sources.redhat.com/git/gitweb.cgi?p=cluster.git;a=commitdiff;h=ff934655dbb265150c7c9ae5e499645be26ab586 The branch, STABLE2 has been updated via ff934655dbb265150c7c9ae5e499645be26ab586 (commit) from 8819aeb2ea8d74c23c4af717bec8d55f8fcdb263 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit ff934655dbb265150c7c9ae5e499645be26ab586 Author: David Teigland Date: Wed Jul 23 12:57:49 2008 -0500 fenced: update cman only after complete success bz 456403 Problem discovered by Lon: tell cman about a completed fencing operation only after all devices within a method have completed successfully. Otherwise, if the first device succeeds, cman will be told the node is fenced, even if the second device fails. When fenced subsequently retries the fencing, it asks cman if fencing is complete, and is wrongly told it is (the purpose of asking cman is to avoid double fencing when a node is fenced externally via fence_node). So, a failed node can be considered successfully fenced when it hasn't been. Signed-off-by: David Teigland ----------------------------------------------------------------------- Summary of changes: fence/fenced/agent.c | 16 +++++++++------- 1 files changed, 9 insertions(+), 7 deletions(-) diff --git a/fence/fenced/agent.c b/fence/fenced/agent.c index 86c5bde..033f447 100644 --- a/fence/fenced/agent.c +++ b/fence/fenced/agent.c @@ -291,10 +291,13 @@ void update_cman(char *victim, char *method) int dispatch_fence_agent(char *victim, int force) { + char good_device[256]; char *method = NULL, *device = NULL; char *victim_nodename = NULL; int num_methods, num_devices, m, d, error = -1, cd; + strcpy(good_device, "UNKNOWN"); + if (force) cd = ccs_force_connect(NULL, 0); else { @@ -322,16 +325,13 @@ int dispatch_fence_agent(char *victim, int force) if (error == -EBADR) { syslog(LOG_INFO, "ccs connection timed out, " "retrying\n"); - while ((cd = ccs_connect()) < 0) sleep(1); - error = get_method(cd, victim, m, &method); - + } + if (error) continue; - } else if (error) - continue; /* if num_devices is zero we should return an error */ error = -1; @@ -347,7 +347,7 @@ int dispatch_fence_agent(char *victim, int force) if (error) break; - update_cman(victim, device); + strncpy(good_device, device, sizeof(good_device)); free(device); device = NULL; } @@ -358,8 +358,10 @@ int dispatch_fence_agent(char *victim, int force) free(victim_nodename); free(method); - if (!error) + if (!error) { + update_cman(victim, good_device); break; + } } ccs_disconnect(cd); hooks/post-receive -- Cluster Project