Creating the Package Control Script

The package control script contains all the information necessary to run all the services in the package, monitor them during operation, react to a failure, and halt the package when necessary. You can use Serviceguard Manager (in Guided Mode) to create the control script as it creates your package configuration. You can also use HP-UX commands to create or modify the package control script.

Using Serviceguard Manager to Create the Package Control Script

Using the guided method in Serviceguard Manager, a standard control script can be automatically created in the configuration screens. When you click Apply, it is automatically distributed to all the nodes. Click the Preview button to view the script as it is being created and modified.

You can choose to edit the control script yourself if you wish. After that, however, Serviceguard Manager will not be able to read your edits or to modify the script further.

Serviceguard Manager does not distribute other files, such as the HA-NFS toolkit, the ECM toolkit, or Metrocluster scripts; you have to manually distribute such files.

Using Commands to Create the Package Control Script

Each package must have a separate control script, which must be executable.

For security reasons, it must reside in a directory with the string cmcluster in the path. The control script is placed in the package directory and is given the same name as specified in the RUN_SCRIPT and HALT_SCRIPT parameters in the package ASCII configuration file. The package control script template contains both the run instructions and the halt instructions for the package. You can use a single script for both run and halt operations, or, if you wish, you can create separate scripts.

When you create the CFS/CVM 4.1 multi-node or system multi-node package, Serviceguard automatically creates their control scripts. It is highly recommended that you never edit the configuration or control script files for these packages, although Serviceguard does not forbid it. Create and modify the information using cfs admin commands only.

For failover packages, create the control script by editing the control script (pkg_name.sh) file. Use the following procedure to create the template for the sample failover package pkg1.

First, generate a control script template:

# cmmakepkg -s /etc/cmcluster/pkg1/pkg1.sh

You may customize the script, as described in the section ““Customizing the Package Control Script ”” below.

Creating Failover Packages For Database Products

To coordinate the startup and shutdown of database software with cluster node startup and shutdown, you can use the database template files provided with the separately purchasable Enterprise Cluster Master Toolkit product (B5139DA). These files are found in /opt/cmcluster/toolkit/DB/. Separate toolkits are available for Oracle, Informix, and Sybase. In addition to the standard package control script, you use the special script that is provided for the database. To set up these scripts, follow the instructions that appear in the README file provided with each toolkit.

Customizing the Package Control Script

Check the definitions and declarations at the beginning of the control script using the information in the Package Configuration worksheet. You need to customize as follows:

Update the PATH statement to reflect any required paths needed to start your services.
If you are using LVM, enter the names of volume groups to be activated using the VG[] array parameters, and select the appropriate options for the storage activation command, including options for mounting and unmounting filesystems, if desired. Do not use the VXVM_DG[] or CVM_DG[] parameters for LVM volume groups.
If you are using CVM, enter the names of disk groups to be activated using the CVM_DG[] array parameters, and select the appropriate storage activation command, CVM_ACTIVATION_CMD. Do not use the VG[] or VXVM_DG[] parameters for CVM disk groups.
If you are using VxVM disk groups without CVM, enter the names of VxVM disk groups that will be imported using the VXVM_DG[] array parameters. Enter one disk group per array element. Do not use the CVM_DG[] or VG[] parameters for VxVM disk groups without CVM. Also, do not specify an activation command.
CFS-based disk groups should not be included in the package control script; they are activated by the CFS multi-node packages before standard packages are started.
If you are using mirrored VxVM disks, specify the mirror recovery option VXVOL.
Add the names of logical volumes and the file system that will be mounted on them.
Select the appropriate options for the storage activation command (not applicable for basic VxVM disk groups), and also include options for mounting filesystems, if desired.
Specify the filesystem mount retry and unmount count options.
If your package uses a large number of volume groups or disk groups or mounts a large number of file systems, consider increasing the number of concurrent vgchange, mount/umount, and fsck operations. The default of 1 is adequate for most packages.
Define IP subnet and IP address pairs for your package. IPv4 or IPv6 addresses may be used.
Add service name(s).
Add service command(s)
Add a service restart parameter, if desired.




	NOTE: Use care in defining service run commands. Each run command is executed by the control script in the following way: The cmrunserv command executes each run command and then Serviceguard monitors the process id of the process created by the run command. When the command started by cmrunserv exits, Serviceguard determines that a failure has occurred and takes appropriate action, which may include transferring the package to an adoptive node. If a run command is a shell script that runs some other command and then exits, Serviceguard will consider this normal exit as a failure. To avoid problems in the execution of control scripts, ensure that each run command is the name of an actual service and that its process remains alive until the actual service stops.

If you need to define a set of run and halt operations in addition to the defaults, create functions for them in the sections under the heading CUSTOMER DEFINED FUNCTIONS. If your package needs to run short-lived processes, such as commands to initialize or halt a packaged application, you can also run these from the CUSTOMER DEFINED FUNCTIONS.

How Control Scripts Manage VxVM Disk Groups

VxVM disk groups outside CVM are outside the control of the Serviceguard cluster. The package control script uses standard VxVM commands to import and deport these disk groups. (For details on importing and deporting disk groups, refer to the discussion of the import and deport options in the vxdg man page.)

The control script imports disk groups using the vxdg command with the -tfC options. The -t option specifies that the disk is imported with the noautoimport flag, which means that the disk will not be automatically re-imported at boot time. Since disk groups included in the package control script are only imported by Serviceguard packages, they should not be auto-imported.

The -f option allows the disk group to be imported even if one or more disks (a mirror, for example) is not currently available. The -C option clears any existing host ID that might be written on the disk from a prior activation by another node in the cluster. If the disk had been in use on another node which has gone down with a TOC, then its host ID may still be written on the disk, and this needs to be cleared so the new node’s ID can be written to the disk. Note that the disk groups are not imported clearing the host ID if the host ID is set and matches a node that is not in a failed state. This is to prevent accidental importation of a disk group on multiple nodes which could result in data corruption.




	CAUTION: Although Serviceguard uses the -C option within the package control script framework, this option should not normally be used from the command line. The “Troubleshooting” section shows some situations where you might need to use -C from the command line.

The following example shows the command with the same options that are used by the control script:

# vxdg -tfC import dg_01

This command takes over ownership of all the disks in disk group dg_01, even though the disk currently has a different host ID written on it. The command writes the current node’s host ID on all disks in disk group dg_01 and sets the noautoimport flag for the disks. This flag prevents a disk group from being automatically re-imported by a node following a reboot. If a node in the cluster fails, the host ID is still written on each disk in the disk group. However, if the node is part of a Serviceguard cluster then on reboot the host ID will be cleared by the owning node from all disks which have the noautoimport flag set, even if the disk group is not under Serviceguard control. This allows all cluster nodes, which have access to the disk group, to be able to import the disks as part of cluster operation.

The control script also uses the vxvol startall command to start up the logical volumes in each disk group that is imported.

Optimizing for Large Numbers of Storage Units

A set of four variables is provided to allow performance improvement when employing a large number of filesystems or storage groups. For more detail, see the comments in the control script template. The three variables are summarized below

CONCURRENT_VGCHANGE_OPERATIONS—defines a number of parallel LVM volume group activations during package startup as well and deactivations during package shutdown.
CONCURRENT_FSCK_OPERATIONS—defines a number of parallel fsck operations that will be carried out at package startup.
CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS—defines a number of parallel mount operations during package startup and unmount operations during package shutdown.

You can use the -s option with FSCK_OPT and FS_UMOUNT_OPT parameters for environments that use a large number of filesystems. The -s option allows mount/umounts and fscks to be done in parallel. (With the standard 11iv1 (11.11) HP-UX, you need to install patches to get this option.)

Package Control Script Template File

The following is an excerpt from the package control script template file. The file contains separate sections for activation of VxVM and LVM storage groups:

 
# **********************************************************************
# *                                                                    *
# *        HIGH AVAILABILITY PACKAGE CONTROL SCRIPT (template)         *
# *                                                                    *
# *       Note: This file MUST be edited before it can be used.        *
# *                                                                    *
# **********************************************************************
 
# The PACKAGE and NODE environment variables are set by
# Serviceguard at the time the control script is executed.
# Do not set these environment variables yourself!
# The package may fail to start or halt if the values for
# these environment variables are altered.
 
. ${SGCONFFILE:=/etc/cmcluster.conf}
 
# UNCOMMENT the variables as you set them.
 
# Set PATH to reference the appropriate directories.
PATH=$SGSBIN:/usr/bin:/usr/sbin:/etc:/bin
 
# VOLUME GROUP ACTIVATION:
# Specify the method of activation for volume groups.
# Leave the default (“VGCHANGE=”vgchange -a e”) if you want volume
# groups activated in exclusive mode. This assumes the volume groups have
# been initialized with ‘vgchange -c y’ at the time of creation.
#
# Uncomment the first line (VGCHANGE=”vgchange -a e -q n”), and comment
# out the default, if your disks are mirrored on separate physical paths,
#
# Uncomment the second line (VGCHANGE=”vgchange -a e -q n -s”), and comment
# and you want the mirror resynchronization to ocurr in parallel with
# the package startup.
#
# Uncomment the third line (VGCHANGE=”vgchange -a y”) if you wish to
# use non-exclusive activation mode. Single node cluster configurations
# must use non-exclusive activation.
#
# VGCHANGE=”vgchange -a e -q n”
# VGCHANGE=”vgchange -a e -q n -s”
# VGCHANGE=”vgchange -a y”
VGCHANGE=”vgchange -a e”                # Default
 
# CVM DISK GROUP ACTIVATION:
# Specify the method of activation for CVM disk groups.
# Leave the default
# (CVM_ACTIVATION_CMD=”vxdg -g \$DiskGroup set activation=exclusivewrite”)
# if you want disk groups activated in the exclusive write mode.
#
# Uncomment the first line
# (CVM_ACTIVATION_CMD=”vxdg -g \$DiskGroup set activation=readonly”),
# and comment out the default, if you want disk groups activated in
# the readonly mode.
#
# Uncomment the second line
# (CVM_ACTIVATION_CMD=”vxdg -g \$DiskGroup set activation=sharedread”),
# and comment out the default, if you want disk groups activated in the
# shared read mode.
#
# Uncomment the third line
# (CVM_ACTIVATION_CMD=”vxdg -g \$DiskGroup set activation=sharedwrite”),
# and comment out the default, if you want disk groups activated in the
# shared write mode.
#
# CVM_ACTIVATION_CMD=”vxdg -g \$DiskGroup set activation=readonly”
# CVM_ACTIVATION_CMD=”vxdg -g \$DiskGroup set activation=sharedread”
# CVM_ACTIVATION_CMD=”vxdg -g \$DiskGroup set activation=sharedwrite”
CVM_ACTIVATION_CMD=”vxdg -g \$DiskGroup set activation=exclusivewrite”
 
# VOLUME GROUPS
# Specify which volume groups are used by this package. Uncomment VG[0]=””
# and fill in the name of your first volume group. You must begin with
# VG[0], and increment the list in sequence.
#
# For example, if this package uses your volume groups vg01 and vg02, enter:
#         VG[0]=vg01
#         VG[1]=vg02
#
# The volume group activation method is defined above. The filesystems
# associated with these volume groups are specified below.
#
#VG[0]=””
#
# CVM DISK GROUPS
# Specify which cvm disk groups are used by this package. Uncomment
# CVM_DG[0]=”” and fill in the name of your first disk group. You must
# begin with CVM_DG[0], and increment the list in sequence.
#
# For example, if this package uses your disk groups dg01 and dg02, enter:
#         CVM_DG[0]=dg01
#         CVM_DG[1]=dg02
#
# The cvm disk group activation method is defined above. The filesystems
# associated with these volume groups are specified below in the CVM_
# variables.
#
# NOTE: Do not use CVM and VxVM disk group parameters to reference 
# devices used by CFS (cluster file system).  CFS resources are 
# controlled by the Disk Group and Mount Multi-node packages. 
#
#CVM_DG[0]=””
# NOTE: Do not use CVM and VxVM disk group parameters to reference 
# devices used by CFS (cluster file system).  CFS resources are 
# controlled by the Disk Group and Mount Multi-node packages. 
#
# VxVM DISK GROUPS
# Specify which VxVM disk groups are used by this package. Uncomment
# VXVM_DG[0]=”” and fill in the name of your first disk group. You must
# begin with VXVM_DG[0], and increment the list in sequence.
#
# For example, if this package uses your disk groups dg01 and dg02, enter:
#         VXVM_DG[0]=dg01
#         VXVM_DG[1]=dg02
#
# The cvm disk group activation method is defined above.
#
#VXVM_DG[0]=””
 
#
# NOTE: A package could have LVM volume groups, CVM disk groups and VxVM
#       disk groups.
#
# NOTE: When VxVM is initialized it will store the hostname of the
#       local node in its volboot file in a variable called ‘hostid’.
#       The MC Serviceguard package control scripts use both the values of
#       the hostname(1m) command and the VxVM hostid. As a result
#       the VxVM hostid should always match the value of the
#       hostname(1m) command.
#
#       If you modify the local host name after VxVM has been
#       initialized and such that hostname(1m) does not equal uname -n,
#       you need to use the vxdctl(1m) command to set the VxVM hostid
#       field to the value of hostname(1m). Failure to do so will
#       result in the package failing to start.
 
# FILESYSTEMS
# Filesystems are defined as entries specifying the logical volume, the
# mount point, the mount, umount and fsck options and type of the file system.
# Each filesystem will be fsck’d prior to being mounted. The filesystems
# will be mounted in the order specified during package startup and will
# be unmounted in reverse order during package shutdown. Ensure that
# volume groups referenced by the logical volume definitions below are
# included in volume group definitions above.
#
# Specify the filesystems which are used by this package. Uncomment
# LV[0]=””; FS[0]=””; FS_MOUNT_OPT[0]=””; FS_UMOUNT_OPT[0]=””;
# FS_FSCK_OPT[0]=”” FS_TYPE[0]=”” and fill in the name of your 
# first logical volume, filesystem, mount, umount and fsck options 
# and filesystem type for the file system. 
# You must begin with LV[0], FS[0],
# FS_MOUNT_OPT[0], FS_UMOUNT_OPT[0], FS_FSCK_OPT[0], FS_TYPE[0]
# and increment the list in sequence.
#
# Note: The FS_TYPE parameter lets you specify the type of filesystem to be
# mounted. Specifying a particular FS_TYPE will improve package failover time.
 
# The FSCK_OPT and FS_UMOUNT_OPT parameters can be used to include the
# -s option with the fsck and umount commands to improve performance for
# environments that use a large number of filesystems. (An example of a
# large environment is given below following the decription of the
# CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS parameter.)
#
# Example: If a package uses two JFS filesystems, pkg01a and pkg01b,
# which are mounted on LVM logical volumes lvol1 and lvol2 for read and
# write operation, you would enter the following:
#      LV[0]=/dev/vg01/lvol1; FS[0]=/pkg01a; FS_MOUNT_OPT[0]=”-o rw”;
#      FS_UMOUNT_OPT[0]=””; FS_FSCK_OPT[0]=””; FS_TYPE[0]=”vxfs”
#
#      LV[1]=/dev/vg01/lvol2; FS[1]=/pkg01b; FS_MOUNT_OPT[1]=”-o rw”
#      FS_UMOUNT_OPT[1]=””; FS_FSCK_OPT[1]=””; FS_TYPE[1]=”vxfs”
#
#LV[0]=””; FS[0]=””; FS_MOUNT_OPT[0]=””; FS_UMOUNT_OPT[0]=””;FS_FSCK_OPT[0]=””
#FS_TYPE[0]=””
#
# VOLUME RECOVERY
#
# When mirrored VxVM volumes are started during the package control
# bring up, if recovery is required the default behavior is for
# the package control script to wait until recovery has been
# completed.
#
# To allow mirror resynchronization to ocurr in parallel with
# the package startup, uncomment the line
# VXVOL=”vxvol -g \$DiskGroup -o bg startall” and comment out the default.
#
# VXVOL=”vxvol -g \$DiskGroup -o bg startall”
VXVOL=”vxvol -g \$DiskGroup startall”      # Default
 
# FILESYSTEM UNMOUNT COUNT
# Specify the number of unmount attempts for each filesystem during package
# shutdown.  The default is set to 1.
FS_UMOUNT_COUNT=1
 
# FILESYSTEM MOUNT RETRY COUNT.
# Specify the number of mount retrys for each filesystem.
# The default is 0. During startup, if a mount point is busy
# and FS_MOUNT_RETRY_COUNT is 0, package startup will fail and
# the script will exit with 1.  If a mount point is busy and
# FS_MOUNT_RETRY_COUNT is greater than 0, the script will attempt
# to kill the user responsible for the busy mount point
# and then mount the file system.  It will attempt to kill user and
# retry mount, for the number of times specified in FS_MOUNT_RETRY_COUNT.
# If the mount still fails after this number of attempts, the script
# will exit with 1.
 
# NOTE: If the FS_MOUNT_RETRY_COUNT > 0, the script will execute
# “fuser -ku” to freeup busy mount point.
FS_MOUNT_RETRY_COUNT=0
## Configuring the concurrent operations below can be used to improve the
# performance for starting up or halting a package.  The maximum value for
# each concurrent operation parameter is 1024.  Set these values carefully.
# The performance could actually decrease if the values are set too high
# for the system resources available on your cluster nodes.  Some examples
# of system resources that can affect the optimum number of concurrent
# operations are: number of CPUs, amount of available memory, the kernel
# configuration for nfile and nproc. In some cases, if you set the number
# of concurrent operations too high, the package may not be able to start
# or to halt.  For example, if you set CONCURRENT_VGCHANGE_OPERATIONS=5
# and the node where the package is started has only one processor, then
# running concurrent volume group activations will not be beneficial.
# It is suggested that the number of concurrent operations be tuned
# carefully, increasing the values a little at a time and observing the
# effect on the performance, and the values should never be set to a value
# where the performance levels off or declines.  Additionally, the values
# used should take into account the node with the least resources in the
# cluster, and how many other packages may be running on the node.
# For instance, if you tune the concurrent operations for a package so
# that it provides optimum performance for the package on a node while
# no other packages are running on that node, the package performance
# may be significantly reduced, or may even fail when other packages are
# already running on that node.
#
# CONCURRENT VGCHANGE OPERATIONS
# Specify the number of concurrent volume group activations or
# deactivations to allow during package startup or shutdown.
# Setting this value to an appropriate number may improve the performance
# while activating or deactivating a large number of volume groups in the
# package. If the specified value is less than 1, the script defaults it
# to 1 and proceeds with a warning message in the package control script
# logfile.
CONCURRENT_VGCHANGE_OPERATIONS=1
#
# CONCURRENT FSCK OPERATIONS
# Specify the number of concurrent fsck to allow during package startup.
# Setting this value to an appropriate number may improve the performance
# while checking a large number of file systems in the package. If the
# specified value is less than 1, the script defaults it to 1 and proceeds
# with a warning message in the package control script logfile.
CONCURRENT_FSCK_OPERATIONS=1
 
# CONCURRENT MOUNT AND UMOUNT OPERATIONS
# Specify the number of concurrent mounts and umounts to allow during
# package startup or shutdown.
# Setting this value to an appropriate number may improve the performance
# while mounting or un-mounting a large number of file systems in the package.
 
# If the specified value is less than 1, the script defaults it to 1 and
# proceeds with a warning message in the package control script logfile.
CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS=1
 
# Example:  If a package uses 50 JFS filesystems, pkg01aa through pkg01bx,
# which are mounted on the 50 logical volumes lvol1..lvol50 for read and write
# operation, you may enter the following:
#
#      CONCURRENT_FSCK_OPERATIONS=50
#      CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS=50
#
#      LV[0]=/dev/vg01/lvol1; FS[0]=/pkg01aa; FS_MOUNT_OPT[0]=”-o rw”;
#      FS_UMOUNT_OPT[0]=”-s”; FS_FSCK_OPT[0]=”-s”; FS_TYPE[0]=”vxfs”
#
#      LV[1]=/dev/vg01/lvol2; FS[1]=/pkg01ab; FS_MOUNT_OPT[1]=”-o rw”
#      FS_UMOUNT_OPT[1]=”-s”; FS_FSCK_OPT[1]=”-s”; FS_TYPE[0]=”vxfs”
#         :           :          :
#         :           :          :
#         :           :          :
#      LV[49]=/dev/vg01/lvol50; FS[49]=/pkg01bx; FS_MOUNT_OPT[49]=”-o rw”
#      FS_UMOUNT_OPT[49]=”-s”; FS_FSCK_OPT[49]=”-s”; FS_TYPE[0]=”vxfs”
#
# IP ADDRESSES
# Specify the IP and Subnet address pairs which are used by this package.
# You could specify IPv4 or IPv6 IP and subnet address pairs.
# Uncomment IP[0]=”” and SUBNET[0]=”” and fill in the name of your first
# IP and subnet address. You must begin with IP[0] and SUBNET[0] and
# increment the list in sequence.
#
# For example, if this package uses an IP of 192.10.25.12 and a subnet of
# 192.10.25.0 enter:
#          IP[0]=192.10.25.12
#          SUBNET[0]=192.10.25.0
#          (netmask=255.255.255.0)
#
# Hint: Run “netstat -i” to see the available subnets in the Network field.
#
# For example, if this package uses an IPv6 IP of 2001::1/64
# The address prefix identifies the subnet as 2001::/64 which is an
# available subnet.
# enter:
#          IP[0]=2001::1
#          SUBNET[0]=2001::/64
#          (netmask=ffff:ffff:ffff:ffff::)
# Alternatively the IPv6 IP/Subnet pair can be specified without the prefix
# for the IPv6 subnet.
#          IP[0]=2001::1
#          SUBNET[0]=2001::
#          (netmask=ffff:ffff:ffff:ffff::)
#
# Hint: Run “netstat -i” to see the available IPv6 subnets by looking
# at the address prefixes
# IP/Subnet address pairs for each IP address you want to add to a subnet
# interface card.  Must be set in pairs, even for IP addresses on the same
# subnet.
#
#IP[0]=””
#SUBNET[0]=””
 
# SERVICE NAMES AND COMMANDS.
# Specify the service name, command, and restart parameters which are
# used by this package. Uncomment SERVICE_NAME[0]=””, SERVICE_CMD[0]=””,
# SERVICE_RESTART[0]=”” and fill in the name of the first service, command,
# and restart parameters. You must begin with SERVICE_NAME[0],SERVICE_CMD[0],
# and SERVICE_RESTART[0] and increment the list in sequence.
#
# For example:
#          SERVICE_NAME[0]=pkg1a
#          SERVICE_CMD[0]=”/usr/bin/X11/xclock -display 192.10.25.54:0”
#          SERVICE_RESTART[0]=””  # Will not restart the service.
#
#          SERVICE_NAME[1]=pkg1b
#          SERVICE_CMD[1]=”/usr/bin/X11/xload -display 192.10.25.54:0”
#          SERVICE_RESTART[1]=”-r 2”   # Will restart the service twice.
#
#          SERVICE_NAME[2]=pkg1c
#          SERVICE_CMD[2]=”/usr/sbin/ping”
#          SERVICE_RESTART[2]=”-R” # Will restart the service an infinite
#                                    number of times.
#
# Note: No environmental variables will be passed to the command, this
# includes the PATH variable. Absolute path names are required for the
# service command definition.  Default shell is /usr/bin/sh.
#
#SERVICE_NAME[0]=””
#SERVICE_CMD[0]=””
#SERVICE_RESTART[0]=””
 
# DEFERRED_RESOURCE NAME
# Specify the full path name of the ‘DEFERRED’ resources configured for
# this package.  Uncomment DEFERRED_RESOURCE_NAME[0]=”” and fill in the
# full path name of the resource.
#
#DEFERRED_RESOURCE_NAME[0]=””
 
# DTC manager information for each DTC.
# Example: DTC[0]=dtc_20
#DTC_NAME[0]=
# 
#HA_NFS_SCRIPT_EXTENSION
# If the package uses HA NFS, this variable can be used to alter the
# name of the HA NFS script.  If not set, the name of this script is
# assumed to be "ha_nfs.sh".  If set, the "sh" portion of the default
# script name is replaced by the value of this variable.  So if
# HA_NFS_SCRIPT_EXTENSION is set to "package1.sh", for example, the name
# of the HA NFS script becomes "ha_nfs.package1.sh".  In any case,
# the HA NFS script must be placed in the same directory as the package
# control script.  This allows multiple packages to be run out of the# same directory, as needed by SGeSAP.
#HA_NFS_SCRIPT_EXTENSION=""

The above excerpt from the control script shows the assignment of values to a set of variables. The remainder of the script uses these variables to control the package by executing Logical Volume Manager commands, HP-UX commands, and Serviceguard commands including cmrunserv, cmmodnet, and cmhaltserv. Examine a copy of the control script template to see the flow of logic. Use the following command:

# cmmakepkg -s | more

The main function appears at the end of the script.

Note that individual variables are optional; you should include only as many as you need for proper package operation. For example, if your package does not need to activate a volume group, omit the VG variables; if the package does not use services, omit the corresponding SERVICE_NAME, SERVICE_CMD, and SERVICE_RESTART variables; and so on.

If you have defined an EMS resource in the package configuration file that is labeled as DEFERRED, you need to define a DEFERRED_RESOURCE_NAME in the package control script. Specify only the deferred resources, using the DEFERRED_RESOURCE_NAME parameter:

DEFERRED_RESOURCE_NAME[0]="/net/interfaces/lan/status/lan0"
DEFERRED_RESOURCE_NAME[1]="/net/interfaces/lan/status/lan1"

After customizing the script, distribute it to each node in the cluster using rcp, ftp, or your favorite method of copying.

Adding Customer Defined Functions to the Package Control Script

You can add additional shell commands to the package control script to be executed whenever the package starts or stops. Simply enter these commands in the CUSTOMER DEFINED FUNCTIONS area of the script. This gives you the ability to further customize the control script.

An example of this portion of the script is shown below, with the date and echo commands included to log starts and halts of the package to a special file.

# START OF CUSTOMER DEFINED FUNCTIONS
 
# This function is a place holder for customer defined functions.
# You should define all actions you want to happen here, before the service is
# started.  You can create as many functions as you need.
 
function customer_defined_run_cmds
{
# ADD customer defined run commands.
: # do nothing instruction, because a function must contain some command.
 date >> /tmp/pkg1.datelog
 echo 'Starting pkg1' >> /tmp/pkg1.datelog
 test_return 51
}
 
# This function is a place holder for customer defined functions.
# You should define all actions you want to happen here, before the service is
# halted.
 
function customer_defined_halt_cmds
{
# ADD customer defined halt commands.
: # do nothing instruction, because a function must contain some command.
 date >> /tmp/pkg1.datelog
 echo 'Halting pkg1' >> /tmp/pkg1.datelog
 test_return 52
}
 
# END OF CUSTOMER DEFINED FUNCTIONS

Adding Serviceguard Commands in Customer Defined Functions

You can add Serviceguard commands (such as cmmodpkg) in the Customer Defined Functions section of a package control script. However, these commands must not interact with the package itself.

If you do run Serviceguard commands from the package control script, they must be run as background processes, otherwise the package will hang. This is done by adding a "&" (ampersand) to the end of the command line. For example: cmmodpkg -d <package-name> &

If a Serviceguard command interacts with another package, then you need to check all packages with Serviceguard commands for the possibility of a command loop. For instance, a command loop might occur under the following circumstances. Suppose Pkg1 does a cmmodpkg -d of Pkg2, and Pkg2 does a cmmodpkg -d of Pkg1. If both Pkg1 and Pkg2 start at the same time, Pkg1 tries to cmmodpkg Pkg2. However, that cmmodpkg command has to wait for Pkg2 startup to complete. Pkg2 tries to cmmodpkg Pkg1, but Pkg2 has to wait for Pkg1 startup to complete, thereby causing a command loop.

To avoid this situation, it is a good idea to always specify a RUN_SCRIPT_TIMEOUT and a HALT_SCRIPT_TIMEOUT for all packages, especially packages that use Serviceguard commands in their control scripts. If a timeout is not specified and your configuration has a command loop as described above, inconsistent results can occur, including a hung cluster.

Support for Additional Products

The package control script template provides exits for use with additional products, including MetroCluster with Continuous Access/CA, MetroCluster with EMC SRDF, and the HA NFS toolkit. Refer to the additional product’s documentation for details about how to create a package using the hooks that are provided in the control script.