Hide Forgot
Description of problem: The fence_xvm fence agent supports a "delay" option that defaults to 0. Previously, it was possible to explicitly specify "delay=0", but under 7.3, the command gives a usage error. Version-Release number of selected component (if applicable): 0.3.2-5.el7 How reproducible: Reliably Steps to Reproduce: Run fence_xvm with delay set to 0 (either "-w 0" on the command line or "delay=0" on standard input). Actual results: A usage error message with: Invalid delay: '0' Expected results: Successful operation Additional info: This will cause a Pacemaker cluster to get failures for any fence action for a configured device, including start, stop, and monitor, rendering fencing ineffective.
Workaround for Pacemaker is to delete the delay: pcs resource update $FENCING_RESOURCE_NAME delay=
(In reply to Ken Gaillot from comment #1) > Workaround for Pacemaker is to delete the delay: > > pcs resource update $FENCING_RESOURCE_NAME delay= This requires a full cluster stop and start to take effect, but that may be a Pacemaker bug.
I pushed a fix for this: https://github.com/ClusterLabs/fence-virt/commit/d4cd306cb464c12b9d35b062e3de1657c83ef4e0 A fix for a typo (it was checking timeout instead of delay) caused the change in behavior.
Well, this is not correct, either. My assumption back then with https://github.com/ClusterLabs/fence-virt/pull/4 (and consequently https://bugzilla.redhat.com/1204873#fix--delay--parameter-checking) was "ok, let's keep atoi in place, there's a precedence afterall, but at least cover all the misguided values with excluding zero altogether". Old stack/fenced/libfence seems not to be ever passing values other than configured, and it's questionable if explicit zero should be ever accepted (if you want a delay, it's implied it's nonzero[*]). This questionability is the same for pacemaker, IMHO. If something good is to be done about the fence-virt codebase, it should at least move on from very unsuitable "atoi" legacy. Otherwise it's like changing strings on a neck-broken guitar. [*] It would be oh-so-nice if the range of declarable data types followed data types from XML Schema, which would be win also at derived RelaxNG schemas' level, so one could define this as positiveInteger (https://www.w3.org/TR/xmlschema-2/#app-fundamental-facets)
(In reply to Jan Pokorný from comment #5) > Well, this is not correct, either. > > My assumption back then with > https://github.com/ClusterLabs/fence-virt/pull/4 > (and consequently > https://bugzilla.redhat.com/1204873#fix--delay--parameter-checking) > was "ok, let's keep atoi in place, there's a precedence afterall, > but at least cover all the misguided values with excluding zero > altogether". > > Old stack/fenced/libfence seems not to be ever passing values other > than configured, and it's questionable if explicit zero should be > ever accepted (if you want a delay, it's implied it's nonzero[*]). I think an explicit 0 should definitely be accepted: * 0 is semantically valid (delay is logically nonnegative, not positive) * Users may have custom front-end scripts that take some values and do cluster config (which happens to be how I ran into the bug). * It is contrary to expectations that a parameter's default value is illegal. > This questionability is the same for pacemaker, IMHO. > > If something good is to be done about the fence-virt codebase, > it should at least move on from very unsuitable "atoi" legacy. > Otherwise it's like changing strings on a neck-broken guitar. > > > [*] It would be oh-so-nice if the range of declarable data types > followed data types from XML Schema, which would be win also at > derived RelaxNG schemas' level, so one could define this > as positiveInteger > (https://www.w3.org/TR/xmlschema-2/#app-fundamental-facets)
Yes, I agree 0 should be accepted, but it should use strtol or similar instead. I only kept the atoi to make the smallest change possible to restore the old behavior. I can go through the codebase to make these checks more robust throughout the codebase.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2089