Managing HP Serviceguard A.11.20.10 for Linux, December 2012

4.8.7.4.2 Rules for different_node and any_node Dependencies
These rules apply to packages whose dependency_condition is UP and whose
dependency_location is different_node or any_node. For same-node dependencies,
see Simple Dependencies (page 108); for exclusionary dependencies, see “Rules for Exclusionary
Dependencies” (page 113).
• Both packages must be failover packages whose failover_policy (page 172) is
configured_node.
• The priority (page 173) of the package depended on must be higher than or equal to the
priority of the dependent package and the priorities of that package's dependents.
◦ For example, if pkg1 has a different_node or any_node dependency on pkg2,
pkg2's priority must be higher than or equal to pkg1's priority and the priority of any
package that depends on pkg1 to be UP. pkg2's node order dominates when
Serviceguard is placing the packages.
• A package cannot depend on itself, directly or indirectly.
For example, not only must pkg1 not specify itself in the dependency_condition (page 174),
but pkg1 must not specify a dependency on pkg2 if pkg2 depends on pkg1, or if pkg2
depends on pkg3 which depends on pkg1, etc.
• “Dragging” rules apply. See “Dragging Rules for Simple Dependencies” (page 109).
4.8.8 What Happens When a Package Fails
This discussion applies to packages that have dependents, or are depended on, or both (UP
dependencies only). When such a package fails, Serviceguard does the following:
1. Halts the packages that depend on the failing package, if any.
Serviceguard halts the dependent packages (and any packages that depend on them, etc.)
This happens regardless of the priority of the failed package.
NOTE: Dependent packages are halted even in the case of different_node or any_node
dependency. For example, if pkg1 running on node1 has a different_node or any_node
dependency on pkg2 running on node2, and pkg2 fails over to node3, pkg1 will be halted
and restarted as described below.
By default the packages are halted in the reverse of the order in which they were started; and
if the halt script for any of the dependent packages hangs, the failed package will wait
indefinitely to complete its own halt process. This provides the best chance for all the dependent
packages to halt cleanly, but it may not be the behavior you want. You can change it by
means of the successor_halt_timeout parameter (page 172). (A successor is a package
that depends on another package.)
If the failed package's successor_halt_timeout is set to zero, Serviceguard will halt the
dependent packages in parallel with the failed package; if it is set to a positive number,
Serviceguard will halt the packages in the reverse of the start order, but will allow the failed
package to halt after the successor_halt_timeout number of seconds whether or not
the dependent packages have completed their halt scripts.
2. Halts the failing package.
After the successor halt timer has expired or the dependent packages have all halted,
Serviceguard starts the halt script of the failing package, regardless of whether the dependents'
halts succeeded, failed, or timed out.
3. Halts packages the failing package depends on, starting with the package this package
immediately depends on. The packages are halted only if:
114 Planning and Documenting an HA Cluster