Considerations for pre-event and post-event scripts

Edit online

Take into account the following information when planning your pre-event and post-event scripts.

Using shell environment variables in pre-event and post-event scripts

When writing your pre-event or post-event script, none of the shell environment variables defined in /etc/environment are available to your program. If you need to use any of these variables, for example, PATH and NLSPATH, you must explicitly source them by including this line in your script:

. /etc/environment

event_error now indicates failure on a remote node

All cluster nodes run the event_error event if any node has an unrecoverable error. All nodes log the error and call out the failing node name in the hacmp.out log file. If you have added pre-event or post-event scripts for the event_error event, be aware that they are called on each node, not just on the failing node.

An environment variable that indicates the node where the event script failed, EVENT_FAILED_NODE, is set to the name of the node where the event occurred. Use this variable in your pre-event or post-event scripts to locate the failure.

The variable LOCALNODENAME identifies the local node; if LOCALNODENAME is not the same as EVENT_FAILED_NODE, then the failure occurred on a remote node.

Parallel processing of resource groups affects event processing

When resource groups are processed in parallel, fewer cluster events occur in the cluster. In particular, only node_up and node_down events take place, and events such as node_up_local or get_disk_vg_fs do not occur. This is because PowerHA® SystemMirror® uses other methods to process resources in parallel. As a result, the use of parallel processing reduces the number of particular cluster events for which you can create customized pre-event or post-event scripts. If you start using parallel processing for some of the resource groups in your configuration, be aware that your existing event scripts may not work for the resource groups.

Dependent resource groups and the use of pre-event and post-event scripts

If you are using pre-event and post-event scripts or other methods, such as customized serial resource group processing to establish dependencies between applications that are supported by your cluster, then these methods may no longer be needed or can be significantly simplified. Instead, you can specify dependencies between resource groups in a cluster. For more information on how to configure resource group dependencies, see Configuring dependencies between resource groups.

If you still want to customize behavior for some applications, consider adding a pre-event or post-event script to the resource_state_change event.

How notification, pre and post events affect execution of cluster events?

Notification script(s) are invoked as background processes and do not affect the rest of the calling sequence, in other words, the return code from a notification script is ignored.

Pre and post scripts or custom events are invoked in the foreground. By default the return code from a pre or post event is ignored, however, you can change this behavior such that a non-zero return code is treated as an event failure which will terminate any further event processing.

You can configure this option using smit:

Custom Cluster Configuration->Events->Cluster Events->Change/Show Pre-Defined Events

Change the Fail event if pre or post event fails? option to Yes to have the failure of your pre or post event treated as an event failure.

You can also change this option using the clmgr change event command by setting the PREPOSTFAILS option to true.

Refer: ../command/clmgr.htm

The default sequence of invocation for pre, post and notify scripts is as follows:
  • Notify script(s) are invoked as background processes
  • Pre event script(s) are called in the foreground
  • The “main” or predefined event script is called in the foreground
  • Post event script(s) are called in the foreground
  • Notify script(s) are invoked as background processes

If you select the option to fail the event if a pre or post event fails, a failure of any of thoe scripts will be treated the same as a failure of the predefined event and will cause the cluster to enter the RP_FAILED state. The notify script(s) will be run, but no further event processing will occur.

For example, if you select the option to fail the event if a pre event fails, and your pre event script returns non-zero, the sequence of invocations will be:
  • Notify script(s) are invoked as background processes
  • Pre event script(s) is called in the foreground and returns non-zero
  • Notify script(s) are invoked as background processes

In this case neither the main or predefined event script nor any post event script(s) are run.

If you select the option to fail the event if a post event fails, and your post event script returns non-zero, then all scripts will be run in the same sequence as the default case, but the non-zero return code will be treated as an error and the cluster will go to the RP_FAILED state.

If the cluster goes to the RP_FAILED state, you will need to manually recover cluster services as described here: ../trouble/ha_trgd_recover_script.dita