<div dir="ltr"><div dir="ltr">We do not use hardware-watchdog. We did not have SBD watchdog self-fencing configured. Fencing used external power control. <div><br></div><div>That's an excellent guardrail for many use-cases. Thanks for the helpful guidance.<div><br></div><div>My question remains, though. Can we not prevent this particular kind of stall at the source? mlock() would guarantee that the SHM IPC pages remain resident (the executor request, response, and event rings in particular). It's a pretty narrow potential fix, and when coupled with the hardware-watchdog and subdaemon-liveness as a backstop this would tighten Pacemaker guarantees in a meaningful way, yes?</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2026 at 4:39 AM Klaus Wenninger via Users <<a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2026 at 7:57 AM Windl, Ulrich via Users <<a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>





<div lang="DE">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif;color:rgb(31,73,125)">Just wondering: Did you have a working hardware watchdog configured? Wouldn’t it have fenced your node then?</span></p></div></div></div></blockquote><div><br></div><div>Just a side-note:</div><div>If you're using SBD pacemakerd would be observing the pacemaker-subdaemons. And if that gets stuck it would stop sending<br>pings to SBD daemon and that would make SBD kick in and trigger a reboot - via the hardware-watchdog as a final resort if configured.</div><div>That behavior requires a sufficiently current stack of pacemaker & sbd and it has to be configured and built accordingly.</div><div>If you're using watchdog-daemon or alike you have to take care that the proper pacemaker-daemons are observed in one way or<br>the other for the case not the whole machine is hanging (so that the watchdog-daemon process would be hanging anyway).</div><div><br></div><div>Regards,</div><div>Klaus  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div lang="DE"><div><p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Kind regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Ulrich Windl<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-width:medium medium medium 1.5pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor blue;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Users <<a href="mailto:users-bounces@clusterlabs.org" target="_blank">users-bounces@clusterlabs.org</a>>
<b>On Behalf Of </b>Brian Cosgrove<br>
<b>Sent:</b> Tuesday, August 11, 2026 5:28 PM<br>
<b>To:</b> Cluster Labs - All topics related to open-source clustering welcomed <<a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a>><br>
<b>Subject:</b> [EXT] [EXT] Re: [ClusterLabs] Can stalled libqb SHM I/O delay Pacemaker's operation timer?<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks for your reply. Those are great tips, however this was a freak firmware bug. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">"Degraded RAID array" was the wrong wording since that has a precise meaning for RAID. We were not in an ordinary degraded RAID mode with, say, a disk failure in the array. The array itself (or driver, or controller?) was misbehaving. Reads
 were as far as I can tell, actually unbounded: never returning and not erroring. I don't expect it to recur after firmware updates.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">It may, however, have revealed a bug or design flaw in Pacemaker as this is exactly the kind of hardware fault I would expect to trigger fencing and promotion of the hot standby.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Only manual intervention by an operator (as the controller was stalled) led to a successful STONITH (we ran the script by hand, a DC election then occurred and Pacemaker correctly moved the primary database resource and the resource agent
 promoted the hot standby).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I have a draft simple reproduction if it helps maintainers triage this or alternatively help me understand that this was expected behavior and why.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><a href="https://github.com/cosgroveb/pacemaker-shm-timer-repro/blob/main/repro.sh" target="_blank">https://github.com/cosgroveb/pacemaker-shm-timer-repro/blob/main/repro.sh</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">On Tue, Aug 11, 2026 at 8:33 AM Windl, Ulrich via Users <<a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a>> wrote:<u></u><u></u></p>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif;color:rgb(31,73,125)">Hi!</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif;color:rgb(31,73,125)">A non-pacemaker answer: I can imagine two solutions for your problem:</span><u></u><u></u></p>
<ol start="1" type="1">
<li style="color:rgb(31,73,125)">
<span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif">Limit the reconstruction rate of the RAID</span><u></u><u></u></li><li style="color:rgb(31,73,125)">
<span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif">Limit the amount of (dirty) filesystem cache (we had read stalls when someone backed up the database and most of the RAM had been filled with dirty buffers to write out)</span><u></u><u></u></li></ol>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Aptos,serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Kind regards,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Ulrich Windl</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
<div style="border-width:medium medium medium 1.5pt;border-style:none none none solid;padding:0cm 0cm 0cm 4pt;border-color:currentcolor currentcolor currentcolor blue">
<div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0cm 0cm;border-color:currentcolor">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Users <<a href="mailto:users-bounces@clusterlabs.org" target="_blank">users-bounces@clusterlabs.org</a>>
<b>On Behalf Of </b>Brian Cosgrove<br>
<b>Sent:</b> Monday, August 10, 2026 10:03 PM<br>
<b>To:</b> <a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a><br>
<b>Subject:</b> [EXT] [EXT] [ClusterLabs] Can stalled libqb SHM I/O delay Pacemaker's operation timer?</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US">Could Pacemaker’s controller block on a stalled block-device read while faulting in a swapped-<br>
out libqb SHM page, before it receives the executor reply and starts the operation timer? </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
<p class="MsoNormal">Would that behavior be expected? <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I'm investigating a lockup where the PostgreSQL primary and Pacemaker DC were on the same node when a degraded RAID array caused reads to appear unbounded without returning errors.
 Pacemaker did not stop the PostgreSQL resource or promote a standby. crm_mon showed the DC as standby (with active resources).<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Testing that simulates the incident reproduces that production Pacemaker behavior. In that setup a libqb SHM page is swapped out and controller blocks in shmem_fault() before the
 executor reply and operation timer. The surviving production logs (such as the crm_mon output) match. Corosync membership remained intact in both the incident and the test.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span>--
</span><u></u><u></u></p>
<p class="MsoNormal">Brian Cosgrove<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" target="_blank">https://www.clusterlabs.org/</a><u></u><u></u></p>
</blockquote>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span>-- </span><u></u><u></u></p>
<p class="MsoNormal">Brian Cosgrove<u></u><u></u></p>
</div>
</div>
</div>

_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</div></blockquote></div></div>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Brian Cosgrove</div></div>