Managing HP Serviceguard A.12.00.00 for Linux, June 2014

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 188). (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:
• these are failover packages, and
• the failing package can “drag” these packages to a node on which they can all run.
Otherwise the failing package halts and the packages it depends on continue to run
4. Starts the packages the failed package depends on (those halted in step 3, if any).
If the failed package has been able to drag the packages it depends on to the adoptive node,
Serviceguard starts them in the reverse of the order it halted them in the previous step (that is,
the package that does not depend on any other package is started first).
5. Starts the failed package.
6. Starts the packages that depend on the failed package (those halted in step 1).
7. If a package has the all_nodes dependency, and if the package changes to halt_aborted
state, the dependent package does not start. However, if the dependency_condition is
same_node or any_node, the dependent package is started, even if the dependent package
is in halt_aborted state.
4.9.9 For More Information
For more information, see:
• The parameter descriptions for priority (page 189) and dependency_ (page 190), and the
corresponding comments in the package configuration template file
• The cmmakepkg (1m) manpage
• The white paper Serviceguard’s Package Dependency Feature, which you can find at http://
www.hp.com/go/linux-serviceguard-docs
4.9.10 About Package Weights
Package weights and node capacities allow you to restrict the number of packages that can run
concurrently on a given node, or, alternatively, to limit the total package “weight” (in terms of
resource consumption) that a node can bear.
For example, suppose you have a two-node cluster consisting of a large system and a smaller
system. You want all your packages to be able to run on the large system at the same time, but,
if the large node fails, you want only the critical packages to run on the smaller system. Package
weights allow you to configure Serviceguard to enforce this behavior.
118 Planning and Documenting an HA Cluster