OpenVMS CLUEXIT crash

The first item to understand is that this crash is a voluntary crash that is the result of a loss of communication at the SCS level. Prior to this crash on Node A, other nodes within the cluster should have received a cluster transition message indicating the loss of connection to Node A. If the transition is short enough, the crash will be avoided and the cluster will continue. If the loss of communication exceeds RECNXINTERVAL (defaults to 20 seconds), Node A will crash. Please note that Node A will “know” how long it has been severed from the cluster and will determine based upon this whether or not to crash when it attempts to reenter the cluster. This is done to prevent any stale data currently “in progress” on Node A from corrupting data that has since been updated in the active cluster. In most cases, the cluster transition would have been completed by the remaining nodes such that work would continue.

It is important to note that the time of the crash is the time when the node is trying to reconnect to the cluster and not the time when the node leaves. This means that this also indicates the time when the communication failure is “fixed”. The time of the cluster transition showing the loss of communication to Node A on all other nodes and the time of the CLUEXIT crash on Node A should represent the total time of the communications lapse.

These crash types (crash code 5D8 shown in the Charon log file) indicate a communication failure usually of the network. In one case all 4 nodes in a cluster crashed with this crash type since the network was interrupted for more than 20 seconds. The natural instinct is to increase the RECNXINTERVAL period to prevent this, however that would increase the potential for data corruption as 20 seconds is already a long time to stall cluster update activity. Realize that locks can be stalled for this period in these cases.

While relatively rare, these crash types should be viewed as a signal that there may be network integrity issues.

Two node clusters can also suffer from this but the behavior might be a bit different. If there is no Quorum disk involved, than both nodes will enter cluster transition until the “lost” node returns. Here both nodes will realize that communication was lost and if the RECNXINTERVAL period has been exceeded, both nodes will crash as there is no “master cluster” available as the official time keeper. If there is a quorum disk, than the surviving node will continue and only the “lost” node will crash.