Gianluca, I thought that the sequence when both nodes are down and one starts was: a) Fence daemon notices that the other node is down (with status option of the fence command) b) Fence daemon waits for the configured amount of time, based on cluster.conf values or default ones, to "see" the other node coming up c) after this amount of time fenced completes its start phase and the other ones take place But in c), after waiting post_join_delay, fenced should always trigger a fence over the halted node, anyway, no? it's the expected behavior, as (I think) the node does not know for sure what's happening with the halted node (even if the halted node properly leaved the fencing domain, ie, a clean shudown). I experienced, as commented in my previous post, the same, but even the fence was triggered, the halted node shouldn't start/boot, because of the BIOS settings commented (ie: on a server power fault (or a server hardware fault for the sake) I expect the server to reboot when it gets fenced, but not when the BIOS server-restart code notices a ordered, clean shutdown was issued. alvaro -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
