Managing HP Serviceguard A.11.20.10 for Linux, December 2012

• A package cannot depend on itself, directly or indirectly.
That is, 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.
• 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 173). See “Dragging
Rules for Simple Dependencies” (page 109).
• 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 apkg3 that depends on pkg1,
pkg1 will wait forever for pkg3). You can modify this behavior by means of the
successor_halt_timeout parameter (page 172)). (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.)
4.8.7.2.1 Dragging Rules for Simple Dependencies
The priority parameter (page 173) 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 172) is configured_node. Assume pkg1 depends on pkg2, that
node1, node2 and node3 are all specified (in some order) under node_name (page 170) in the
configuration file for each package, and that failback_policy (page 173) is set to automatic
for each package.
4.8 Package Configuration Planning 109