[ClusterLabs] Antw: [EXT] "Error: unable to fence '001db02a'" but It got fenced anyway

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Mon Mar 1 02:48:58 EST 2021


>>> Eric Robinson <eric.robinson at psmnv.com> schrieb am 28.02.2021 um 16:34 in
Nachricht
<SA2PR03MB5884B344F832DFAFCC422259FA9B9 at SA2PR03MB5884.namprd03.prod.outlook.com>

> I just configured STONITH in Azure for the first time. My initial test went

> fine.
> 
> On node 001db02a, the command...
> 
> # pcs stonith fence 001db02b
> 
> ...produced output...
> 
> 001db02b fenced.
> 
> 001db02b rebooted. After it came back up, I tried it in the other
direction.
> 
> On node 001db02b, the command...
> 
> # pcs stonith fence 001db02a
> 
> ...produced output...
> 
> Error: unable to fence '001db02a'.
> 
> However, node 001db02a did get restarted!
> 
> We also saw this error...
> 
> Failed Actions:
> * stonith‑001db02ab_start_0 on 001db02a 'unknown error' (1): call=70, 
> status=Timed Out, exitreason='',
>     last‑rc‑change='Sun Feb 28 10:11:10 2021', queued=0ms, exec=20014ms
> 
> When that happens, does Pacemaker take over the other node's resources, or 
> not?

In case you are debugging an "unsuccessful" stonith that actually reboots the
node, you might try something likle "journalctl -f" on the node to be fenced,
just in case the last messages are not written to disk.
Generally no stonith can send a confirmation response _after_ stonith was
successful, so usually it works with timeouts (assuming the node is down n
seconds after issuing stonith to it).

> 
> 
> [cid:image001.png at 01D70DB2.BF2769D0]
> 
> Disclaimer : This email and any files transmitted with it are confidential 
> and intended solely for intended recipients. If you are not the named 
> addressee you should not disseminate, distribute, copy or alter this email.

> Any views or opinions presented in this email are solely those of the author

> and might not represent those of Physician Select Management. Warning: 
> Although Physician Select Management has taken reasonable precautions to 
> ensure no viruses are present in this email, the company cannot accept 
> responsibility for any loss or damage arising from the use of this email or

> attachments.





More information about the Users mailing list