Description of problem: We recently introduced the -M option in fence_ipmilan to support different methods to reboot when fencing (either "onoff" or "cycle") in this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=522529 The introduction of this attempts to allow you to set -M if needed. If it is unset after reading in all arguments, we try to default to "onoff" here: if (!strlen(method)) snprintf(method, sizeof(method), "onoff"); A few lines down from here, we test to make sure method is set to either "onoff" or "cycle" and bomb out if it isn't: if (strcasecmp(method, "onoff") && strcasecmp(method, "cycle")) { fail_exit("method, if included, muse be 'onoff', 'cycle'."); Somehow, I kept hitting this block of code and the fence agent kept failing with: failed: method, if included, muse be 'onoff', 'cycle'. even though I wasn't using -M at all. Dropping in a few debug statements and looking through this a bit, I believe this is because we never properly initialize the method variable, so sometimes the random chunk of memory it grabs when allocating "char method[64];" is detected as a non-zero length string. Unfortunately, this isn't always reproducible...sometimes it works fine, other times it fails like above. I also believe this introduces a possible regression, because previously existing clusters using the fence_ipmilan fence agent without a method specified (since it didn't exist until just recently) are vulnerable to breakage because of this. Version-Release number of selected component (if applicable): # rpm -q cman cman-2.0.115-1.el5_4.3 # fence_ipmilan -V fence_ipmilan 2.0.115 (built Sep 29 2009 08:55:13) Copyright (C) Red Hat, Inc. 2004 All rights reserved. How reproducible: Rather randomly. Steps to Reproduce: 1. upgrade to the newest cman package above which includes the new "method" option for fence_ipmilan 2. issue fence_ipmilan without using a -M option Actual results: Sometimes, fencing fails with "failed: method, if included, muse be 'onoff', 'cycle'." Expected results: Fencing event should complete successfully. If no -M is specified, then the option should properly default to "onoff". Additional info: This is a pretty simple one line patch to properly initialize the method variable: diff -up ./fence/agents/ipmilan/ipmilan.c.ORIG ./fence/agents/ipmilan/ipmilan.c --- ./fence/agents/ipmilan/ipmilan.c.ORIG 2009-10-30 16:36:43.000000000 -0400 +++ ./fence/agents/ipmilan/ipmilan.c 2009-10-30 16:37:33.000000000 -0400 @@ -1064,6 +1064,7 @@ main(int argc, char **argv) memset(passwd, 0, sizeof(passwd)); memset(user, 0, sizeof(user)); memset(op, 0, sizeof(op)); + memset(method, 0, sizeof(method)); if (argc > 1) { /*
Created attachment 366859 [details] Proposed patch...
Patch commited to Git RHEL55 branch as SHA1: f81a8d2891bcd679b31a15f4cf3976932c58df05
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: ======= User wants use fence_ipmilan agent, without specifying -M parameter. Consequence: ============ Because memory is not properly initialized, agent called without -M parameter can: - Use onoff method as usual and expected. OR - Fail with message "method, if included, muse be 'onoff', 'cycle'". OR - use cycle method Fix: ==== Correctly initialize -M parameters memory Result: ======= Without using -M, default action is now correctly always onoff.
I would like to know when Red Hat will ship the fix package.
*** Bug 537898 has been marked as a duplicate of this bug. ***
patch verified to be present in cman-2.0.115-31.el5. Random invocations did not show any error while -M not being used.
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 therefore 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-2010-0266.html