Managing Serviceguard A.11.20, March 2013

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.
About External Scripts
The package configuration template for modular scripts 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 256); 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 external_script
(page 256).
The scripts are also run when the package is validated by cmcheckconf and cmapplyconf,
and must have an entry point for validation; see below.
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 317).
Each external script must have three entry points: start, stop, and validate, and should exit
with one of the following values:
• 0 - indicating success.
• 1 - indicating the package will be halted, and should not be restarted, as a result of failure
in this script.
• 2 - indicating the package will be restarted on another node, or halted if no other node is
available.
NOTE: In the case of the validate entry point, exit values 1 and 2 are treated the same; you
can use either to indicate that validation failed.
The script can make use of a standard set of environment variables (including the package name,
SG_PACKAGE, and the name of the local node, SG_NODE) exported by the package manager or
the master control script that runs the package; and can also call a function to source in a logging
function and other utility functions. One of these functions, sg_source_pkg_env(), provides
access to all the parameters configured for this package, including package-specific environment
variables configured via the pev_ parameter (page 256).
Package Configuration Planning 157