3.1.2 Matrix Server Administration Guide

Chapter 13: Configure Device Monitors 183

Start scripts must be robust enough to run when the device is already

started, without considering this to be an error. Similarly, Stop scripts

must be robust enough to run when the device is already stopped,

without considering this to be an error. In both of these cases, the script

should exit with a zero exit status.

This behavior is necessary because Matrix Server runs the Start and Stop

scripts to establish the desired start/stop activity, even though the device

may actually have been started by something other than Matrix Server

before the ClusterPulse daemon was started. The Start and Stop scripts

must also handle recovery from events that may cause them to run

unsuccessfully.

For example, if the system runs out of swap space while running a Start

script, the script will fail and exit non-zero. The device could then become

active on another server, causing the Stop script to run on the original

server even though the Start script did not complete successfully.

To configure scripts from the command line, use these options:

--recoveryScript <script>

--startScript <script>

--stopScript <script>

Event Severity

By default, Matrix Server treats the failure or timeout of a Start or Stop

script as a failure of the associated monitored device and may initiate

failover of the associated virtual hosts. Configuration errors can also

cause this behavior.

Such a failure or timeout creates an event associated with the monitor on

the server where the failure or timeout occurred. You can view these

events in the Management Console and clear them using the Console or

mx device clear command after you have fixed the problems that caused

them.

You can configure the failover behavior with the Event Severity attribute.

There are two settings:

CONSIDER. This is the default value. Events are considered when

Matrix Server makes failover decisions.