Managing Serviceguard Eighteenth Edition, September 2010
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 309); 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 309).
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 387).
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 309).
Package Configuration Planning 197