HP Serviceguard Version A.11.18 Release Notes, September 2008

Other Package Changes
The patches listed under “September 2008 Patch” (page 13) provide the following new
capabilities:
Serviceguard now supplies information explaining why a package has shut down.
Serviceguard will set the new environment variable SG_HALT_REASON in the
package control script to one of the following values when the package halts:
failure - set if the package halts because of the failure of a subnet, resource,
or service it depends on
user_halt - set if the package is halted by a cmhaltpkg or cmhaltnode
command, or by corresponding actions in Serviceguard Manager
automatic_halt - set if the package is failed over automatically because of
the failure of a package it depends on, or is failed back to its primary node
automatically (failback_policy = automatic)
You can add custom code to the package to interrogate this variable, determine
why the package halted, and take appropriate action. For legacy packages, put the
code in the customer_defined_halt_cmds() function in the CUSTOMER
DEFINED FUNCTIONS area of the package control script; for modular packages,
put the code in the package’s external script (see external_script (page 34)).
For example, if a database package is being halted by an administrator
(SG_HALT_REASON set to user_halt) you would probably want the custom
code to perform an orderly shutdown of the database; on the other hand, a forced
shutdown might be needed if SG_HALT_REASON is set to failure,
indicating thatthe package is halting abnormally (for example because of the
failure of a service it depends on).
cmviewcl -v -f line has a new field, last_halt_failed, that shows
whether the last invocation of the halt script of a package on a node succeeded or
failed. The value is no if the halt script ran successfully, or was not run since the
node joined the cluster, or was not run since the package was configured to run
on the node; otherwise it is yes.
A new parameter in the package configuration file, vxvm_dg_retry, allows you
specify that a failed VxVM import should be retried; see vxvm_dg_retry (page 33).
About Cross-Subnet Configurations
As of Serviceguard A.11.18, with the patches listed under “September 2008 Patch”
(page 13), Serviceguard allows you to configure multiple subnets, joined by a router,
both for the cluster heartbeat and for data, with some nodes using one subnet and some
another.
A cross-subnet configuration allows:
Automatic package failover from a node on one subnet to a node on another
A cluster heartbeat that spans subnets.
40 Serviceguard Version A.11.18 Release Notes