Managing HP Serviceguard A.11.20.20 for Linux, March 2014

its priority is set to the default, no_priority) will not be halted to make room for a down
package that has no priority. Between two down packages without priority, Serviceguard will
decide which package to start if it cannot start them both because there is not enough node capacity
to support their weight.
4.8.10.7.1 Example 1
• pkg1 is configured to run on nodes turkey and griffon. It has a weight of 1 and a priority
of 10. It is down and has switching disabled.
• pkg2 is configured to run on nodes turkey and griffon. It has a weight of 1 and a priority
of 20. It is running on node turkey and has switching enabled.
• turkey and griffon can run one package each (package_limit is set to 1).
If you enable switching for pkg1, Serviceguard will halt the lower-priority pkg2 on turkey. It
will then start pkg1 on turkey and restart pkg2 on griffon.
If neither pkg1 nor pkg2 had priority, pkg2 would continue running on turkey and pkg1 would
run on griffon.
4.8.10.7.2 Example 2
• pkg1 is configured to run on nodes turkey and griffon. It has a weight of 1 and a priority
of 10. It is running on node turkey and has switching enabled.
• pkg2 is configured to run on nodes turkey and griffon. It has a weight of 1 and a priority
of 20. It is running on node turkey and has switching enabled.
• pkg3 is configured to run on nodes turkey and griffon. It has a weight of 1 and a priority
of 30. It is down and has switching disabled.
• pkg3 has a same_node dependency on pkg2
• turkey and griffon can run two packages each (package_limit is set to 2).
If you enable switching for pkg3, it will stay down because pkg2, the package it depends on, is
running on node turkey, which is already running two packages (its capacity limit). pkg3 has
a lower priority than pkg2, so it cannot drag it to griffon where they both can run.
4.8.11 About External Scripts
As of Serviceguard A.11.18, the package configuration template for modular packages explicitly
provides for external scripts. These replace the CUSTOMER DEFINED FUNCTIONS in legacy
scripts and can be run either:
• On package startup and shutdown, as essentially the first and last functions the package
performs. These scripts are invoked by means of the parameter external_pre_script
(page 190); or
• During package execution, after volume-groups and file systems are activated, and IP addresses
are assigned, and before the service and resource functions are executed; and again, in the
reverse order, on package shutdown. These scripts are invoked by means of the parameter
external_script (page 190).
The scripts are also run when the package is validated by cmcheckconf and cmapplyconf.
A package can make use of both kinds of script, and can launch more than one of each kind; in
that case the scripts will be executed in the order they are listed in the package configuration file
(and in the reverse order when the package shuts down).
In some cases you can rename or replace an external script while the package that uses it is
running; see “Renaming or Replacing an External Script Used by a Running Package” (page 241).
Each external script must have three entry points: start, stop, and validate, and should exit
with one of the following values:
4.8 Package Configuration Planning 127