Managing Serviceguard Nineteenth Edition, Reprinted June 2011

• If pkg1 is a failover package and pkg2 is a multi-node or system multi-node package, and
pkg2 fails, pkg1 will halt and fail over to the next node on its node_name list on which pkg2
is running (and any other dependencies, such as resource dependencies or a dependency on
a third package, are met).
• In the case of failover packages with a configured_node failover_policy, a set of
rules governs under what circumstances pkg1 can force pkg2 to start on a given node. This
is called dragging and is determined by each package’s priority (page 227). See “Dragging
Rules for Simple Dependencies” (page 130).
• If pkg2 fails, Serviceguard will halt pkg1 and any other packages that depend directly or
indirectly on pkg2.
By default, Serviceguard halts packages in dependency order, the dependent package(s) first,
then the package depended on. In our example, pkg1 would be halted first, then pkg2. If
there were a third package, pkg3, that depended on pkg1, pkg3 would be halted first, then
pkg1, then pkg2.
If the halt script for any dependent package hangs, by default the package depended on will
wait forever (pkg2 will wait forever for pkg1, and if there is a pkg3 that depends on pkg1,
pkg1 will wait forever for pkg3). You can modify this behavior by means of the
successor_halt_timeout parameter (page 225). (The successor of a package depends
on that package; in our example, pkg1 is a successor of pkg2; conversely pkg2 can be
referred to as a predecessor of pkg1.)
Dragging Rules for Simple Dependencies
The priority parameter (page 227) gives you a way to influence the startup, failover, and failback
behavior of a set of failover packages that have a configured_node failover_policy,
when one or more of those packages depend on another or others.
The broad rule is that a higher-priority package can drag a lower-priority package, forcing it to
start on, or move to, a node that suits the higher-priority package.
NOTE: This applies only when the packages are automatically started (package switching
enabled); cmrunpkg will never force a package to halt.
Keep in mind that you do not have to set priority, even when one or more packages depend
on another. The default value, no_priority, may often result in the behavior you want. For
example, if pkg1 depends on pkg2, and priority is set to no_priority for both packages,
and other parameters such as node_name and auto_run are set as recommended in this section,
then pkg1 will normally follow pkg2 to wherever both can run, and this is the common-sense (and
may be the most desirable) outcome.
The following examples express the rules as they apply to two failover packages whose
failover_policy (page 226) is configured_node. Assume pkg1 depends on pkg2, that
node1, node2 and node3 are all specified (not necessarily in that order) under node_name
(page 223) in the configuration file for each package, and that failback_policy (page 227) is
set to automatic for each package.
130 Planning and Documenting an HA Cluster