Managing Serviceguard Eighteenth Edition, September 2010

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 179); for exclusionary dependencies, see “Rules for
Exclusionary Dependencies” (page 185).
• Both packages must be failover packages whose failover_policy (page 292) is
configured_node.
• The priority (page 293) 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 294), 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 181).
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 291). (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
186 Planning and Documenting an HA Cluster