Managing Serviceguard A.11.20, March 2013

You cannot halt a package unless all packages that depend on it are down. If you try, Serviceguard
will take no action, except to send a message indicating that not all dependent packages are
down. Before you halt a system multi-node package, or halt all instances of a multi-node package,
halt any packages that depend on them
Handling Failures During Package Halt
When you halt a package using cmhaltpkg, sometimes errors may occur for various reasons
resulting in the failure of the command. Serviceguard provides an option so that packages can be
halted in a way that when errors occur the halting process is aborted.
When you halt a package using the -a option and one of the non-Serviceguard modules fails with
an exit status of 3, the halt is aborted and the package is moved to a partially_down status
in a halt_aborted state. For information about package status and state, see “Package Status
and State” (page 266).
NOTE: Non-Serviceguard modules are those that are not delivered with the Serviceguard product.
These are additional modules such as those supplied with HP Serviceguard toolkit modules (for
example, ECMT, toolkits for Oracle Data Guard, and so on).
This allows errors to be cleaned up manually during the halt process thus minimizing the risk of
other follow on errors and reducing package downtime.
When a package is in the halt_aborted state, you can do one of the following:
• Run cmhaltpkg and manually halt the package. When this command is run, the halt
re-executes all the modules in the package, but with errors logged into the error log.
• Fix the error manually in the module that caused the package halt to abort and re-run
cmhaltpkg -a <pkg_name>.
When cmhaltpkg -a <pkg_name> is re-run on the partially_down package after the
error is fixed, the halt process begins from the module that had failed and proceeds
sequentially.
For example, consider the following scenario:
You have a package pkgA that is up and running on a node. The package contains the following
modules:
sg-module1
sg-module2
non-sg-module1
non-sg-module2
sg-module3
sg-module4
Now, suppose you run the command cmhaltpkg -a pkgA, if a failure is detected in
non-sg-module2, then the package halt process is aborted at this point and the package is
moved to the halt_aborted state. The command exits and does not proceed further to halt the
sg-module3 and sg-module4 modules.
After fixing the error, if you re-run cmhaltpkg -a pkgA, halt begins from non-sg-module2
and proceeds.
NOTE: This error handling mechanism is applicable only for failover packages and not for
multi-node or system multi-node packages.
It is applicable only for modular packages and not for legacy packages.
If a package is in the detached or maintenance mode, you cannot use the cmhaltpkg -a option.
290 Cluster and Package Maintenance