This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1470262 - disabling a fencing-device that has queued actions leads to stonithd receiving SIGABRT
disabling a fencing-device that has queued actions leads to stonithd receivin...
Status: ON_QA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pacemaker (Show other bugs)
Unspecified Unspecified
urgent Severity urgent
: rc
: 7.5
Assigned To: Ken Gaillot
: ZStream
Depends On:
Blocks: 1481141
  Show dependency treegraph
Reported: 2017-07-12 11:43 EDT by Klaus Wenninger
Modified: 2017-10-10 23:36 EDT (History)
7 users (show)

See Also:
Fixed In Version: pacemaker-1.1.18-1.el7
Doc Type: Bug Fix
Doc Text:
Previously, if a fencing device configured with the pcmk_delay_max setting was disabled while a fencing action was being delayed, Pacemaker's stonithd service attempted to free memory used for the action twice. As a consequence, Pacemaker terminated unexpectedly. With this update, stonithd has been fixed to free the memory only once, and as a result, the described problem no longer occurs.
Story Points: ---
Clone Of:
: 1481141 (view as bug list)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Klaus Wenninger 2017-07-12 11:43:59 EDT
Description of problem:
When a stonith-action is being delayed by pcmk_delay_max (or the new upstream attribute pcmk_delay_base) and the stonith-device is being disabled within
this waiting time stonith coredumps because it receives SIGABRT.

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

How reproducible:

Steps to Reproduce:
1. setup fencing with a fencing-device that has attribute pcmk_delay_max or pcmk_delay_base (just supported with upstream-master at that time)
2. trigger fencing of a node with e.g. pcs
3. use pcs to disable the fencing-resource while the delay configured is running

Actual results:
stonithd core dumps
the pcs-command for fencing is running into a timeout as the communication partner has died

Expected results:
no core dump
immediate failure result of pcs fencing command

Additional info:
Already fixed upstream

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