| Linux FailSafe™ Programmer's Guide | ||
|---|---|---|
| Prev | Chapter 2. Writing the Action Scripts and Adding Monitoring Agents | Next |
Before you can write a new action script, you must understand how action scripts are executed. This section covers the following topics:
Multiple instances of the same script may be executed at the same time. To avoid problems this may cause, you can use the ha_filelock and ha_execute_lock commands to achieve sequential execution of commands in different instances of the same script.
For example, consider a script which modifies a configuration file to start a new application instance. Multiple instances of the script modifying the file simultaneously could cause file corruption and data loss. The start script for the application should use ha_execute_lock when executing the modification script to ensure correct configuration file modification.
Assuming the script is named modify_configuration_file, the start script would contain a statement similar to the following:
${HA_CMDSPATH}/ha_execute_lock 30
${HA_SCRIPTTMPDIR}/lock.volume_assemble \"modify_configuration_file\" |
The ha_execute_lock command takes 3 arguments:
Number of seconds before the command times out waiting for the file lock
File to be used for locking
Command to be executed
The ha_execute_lock command tries to obtain a lock on the file every second for timeout seconds. After obtaining a lock on the file, it executes the command argument. On command completion, it releases lock on the file.
Although the same check can be used in monitor and exclusive action scripts, they are used for different purposes. Table 2-1 summarizes the differences between the scripts.
Table 2-1. Differences Between the monitor and exclusive Action Scripts
exclusive | monitor |
|---|---|
Executed in all nodes in the cluster. | Executed only on the node where the resource group (which contains the resource) is online. |
Executed before the resource is started in the cluster. | Executed when the resource is online in the cluster. (The monitor script could degrade the services provided by the HA server. Therefore, the check performed by the monitor script should be lightweight and less time consuming than the check performed by the exclusive script)) |
Executed only once before the resource group is made online in the cluster. | Executed periodically. |
Failure will result in resource group not becoming online in the cluster. | Failure will cause a resource group failover to another node or a restart of the resource in the local node. An error will cause false resource group failovers in the cluster. |
Table 2-2 shows the state of a resource group after the successful execution of an action script for every resource within a resource group. To view the state of a resource group, use the Cluster Manager graphical user interface (GUI) or the cluster_mgr command.
Table 2-2. Successful Action Script Results
Event | Action Script to Execute | Resource Group State |
|---|---|---|
Resource group is made online on a node | start | online |
Resource group is made offline on a node | stop | offline |
Online status of the resource group | exclusive | (No effect) |
Normal monitoring of online resource group | monitor | online |
Resource group monitoring failure | restart | online |
Table 2-3 shows the state of the resource group and the error state when an action script fails.
You can use the ha_exec2 command to execute action scripts using timeouts. This allows the action script to be completed within the specified time, and permits proper error messages to be logged on failure or timeout. The retry variable is especially useful in monitor and exclusive action scripts.
To retry a command, use the following syntax:
/usr/lib/failsafe/bin/ha_exec2 timeout_in_seconds number_of_retries command_to_be_executed |
For example:
${HA_CMDSPATH}/ha_exec2 30 2 "umount /fs" |
The above ha_exec2 command executes the umount /fs command line. If the command does not complete within 30 seconds, it kills the umount command and retries the command. The ha_exec2 command retries the umount command 2 times if it times out or fails.
For more information, see the ha_exec2 man page.
You can use the ha_exec2 command to send UNIX signals to specific process. A process is identified by its name or its arguments.
For example:
${HA_CMDSPATH}/ha_exec2 -s 0 -t "knfsd" |
The above command sends signal 0 (checks if the process exists) to all processes whose name or arguments match the string knfsd. The command returns 0 if it is a success.
You should use the ha_exec2 command to check for server processes in the monitor script instead of using a ps -ef | grep command line construction, for performance and speed considerations.
For more information, see the ha_exec2 man page.