Managing Serviceguard Nineteenth Edition, Reprinted June 2011

If after cleaning up the node on which the timeout occurred it is desirable to have that node
as an alternate for running the package, remember to re-enable the package to run on the
node:
cmmodpkg -e -n <node-name> <package-name>
The default Serviceguard control scripts are designed to take the straightforward steps needed to
get an application running or stopped. If the package administrator specifies a time limit within
which these steps need to occur and that limit is subsequently exceeded for any reason, Serviceguard
takes the conservative approach that the control script logic must either be hung or defective in
some way. At that point the control script cannot be trusted to perform cleanup actions correctly,
thus the script is terminated and the package administrator is given the opportunity to assess what
cleanup steps must be taken.
If you want the package to switch automatically in the event of a control script timeout, set the
node_fail_fast_enabled parameter (page 233) to yes. In this case, Serviceguard will cause
the node where the control script timed out to halt (system reset). This effectively cleans up any side
effects of the package's run or halt attempt (but remember that the system reset will cause all the
packages running on that node to halt abruptly). In this case the package will be automatically
restarted on any available alternate node for which it is configured. For more information, see
“Responses to Package and Service Failures ” (page 87).
Problems with Cluster File System (CFS)
NOTE: Check the Serviceguard/SGeRAC/SMS/Serviceguard Manager Plug-in Compatibility
and Feature Matrix and the latest Release Notes for your version of Serviceguard for up-to-date
information about support for CFS (http://www.hp.com/go/hpux-serviceguard-docs).
If you have a system multi-node package for Veritas CFS, you may not be able to start the cluster
until SG-CFS-pkg starts. Check SG-CFS-pkg.log for errors.
You will have trouble running the cluster if there is a discrepancy between the CFS cluster and the
Serviceguard cluster. To check, use gabconfig -a.
The ports that must be up are:
1. a — llt, gab
2. b — vxfen
3. v w — cvm
4. f — cfs
You can also check the syslog file for information.
CAUTION: Do not use the HP-UX mount and umount commands in a CFS cluster. Use cfsmount
and cfsumount for legacy CFS packages; cmhaltpkg and cmrunpkg for modular CFS packages.
Commands such as mount -o cluster, dbed_chkptmount, or sfrac_chkptmount could
cause conflicts with subsequent command operations on the file system or Serviceguard packages.
Non-CFS mount commands will not create an appropriate multi-node package, with the result that
the cluster packages are not aware of the file system changes.
Problems with VxVM Disk Groups
This section describes some approaches to solving problems that may occur with VxVM disk groups
in a cluster environment. For most problems, it is helpful to use the vxdg list command to display
the disk groups currently imported on a specific node. Also, you should consult the package control
script log files for messages associated with importing and deporting disk groups on particular
nodes.
Solving Problems 323