Providing Common Functionality to All Methods
This section describes the following functionality that is used in all callback methods of the sample data service:
Identifying the Command Interpreter and Exporting the Path
The first line of a shell script must identify the command interpreter. Each of the method scripts in the sample data service identifies the command interpreter as follows:
#!/bin/ksh |
All method scripts in the sample application export the path to the Sun Cluster binaries and libraries rather than rely on the user's PATH settings.
####################################################################### # MAIN ####################################################################### export PATH=/bin:/usr/bin:/usr/cluster/bin:/usr/sbin:/usr/proc/bin:$PATH |
Declaring the PMF_TAG and SYSLOG_TAG Variables
All the method scripts (with the exception of Validate) use pmfadm to launch (or stop) either the data service or the monitor, passing the name of the resource. Each script defines a variable, PMF_TAG that can be passed to pmfadm to identify either the data service or the monitor.
Likewise each method script uses the logger command to log messages with the system log. Each script defines a variable, SYSLOG_TAG that can be passed to logger with the -t option to identify the resource type, resource group, and resource name of the resource for which the message is being logged.
All methods define SYSLOG_TAG in the same way, as shown in the following sample. The dns_probe, dns_svc_start, dns_svc_stop, and dns_monitor_check methods define PMF_TAG as follows (the use of pmfadm and logger is from the dns_svc_stop method):
#########################################################################
# MAIN
#########################################################################
PMF_TAG=$RESOURCE_NAME.named
SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME
# Send a SIGTERM signal to the data service and wait for 80% of the
# total timeout value.
pmfadm -s $PMF_TAG.named -w $SMOOTH_TIMEOUT TERM
if [ $? -ne 0 ]; then
logger -p ${SYSLOG_FACILITY}.info \
-t [$SYSLOG_TAG] \
“${ARGV0} Failed to stop HA-DNS with SIGTERM; Retry with \
SIGKILL”
|
The dns_monitor_start, dns_monitor_stop, and dns_update, methods define PMF_TAG as follows (the use of pmfadm is from the dns_monitor_stop method):
######################################################################### # MAIN ######################################################################### PMF_TAG=$RESOURCE_NAME.monitor SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME ... # See if the monitor is running, and if so, kill it. if pmfadm -q $PMF_TAG.monitor; then pmfadm -s $PMF_TAG.monitor KILL |
Parsing the Function Arguments
The RGM invokes all of the callback methods—with the exception of Validate—as follows.
method_name -R resource_name -T resource_type_name -G resource_group_name |
The method name is the path name of the program that implements the callback method. A data service specifies the path name for each method in the RTR file. These path names are relative to the directory specified by the Rt_basedir property, also in the RTR file. For example, in the sample data service's RTR file, the base directory and method names are specified as follows.
RT_BASEDIR=/opt/SUNWsample/bin; START = dns_svc_start; STOP = dns_svc_stop; ... |
All callback method arguments are passed as flagged values, with -R indicating the name of the resource instance, -T indicating the type of the resource, and -G indicating the group into which the resource is configured. See the rt_callbacks(1HA) man page for more information on callback methods.
Note –
The Validate method is called with additional arguments (the property values of the resource and resource group on which it is called). See Handling Property Updates for more information.
Each callback method needs a function to parse the arguments it is passed. Because the callbacks are all passed the same arguments, the data service provides a single parse function that is used in all the callbacks in the application.
The following shows the parse_args() function used for the callback methods in the sample application.
#########################################################################
# Parse program arguments.
#
function parse_args # [args ...]
{
typeset opt
while getopts 'R:G:T:' opt
do
case "$opt" in
R)
# Name of the DNS resource.
RESOURCE_NAME=$OPTARG
;;
G)
# Name of the resource group in which the resource is
# configured.
RESOURCEGROUP_NAME=$OPTARG
;;
T)
# Name of the resource type.
RESOURCETYPE_NAME=$OPTARG
;;
*)
logger -p ${SYSLOG_FACILITY}.err \
-t [$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME] \
"ERROR: Option $OPTARG unknown"
exit 1
;;
esac
done
}
|
Note –
Although the PROBE method in the sample application is user defined (not a Sun Cluster callback method), it is called with the same arguments as the callback methods. Therefore, this method contains a parse function identical to the one used by the other callback methods.
The parse function is called in MAIN as:
parse_args “$@” |
Generating Error Messages
It is recommended that callback methods use the syslog facility to output error messages to end users. All callback methods in the sample data service use the scha_cluster_get() function to retrieve the number of the syslog facility used for the cluster log, as follows:
SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY` |
The value is stored in a shell variable, SYSLOG_FACILITY and can be used as the facility of the logger command to log messages in the cluster log. For example, the Start method in the sample data service retrieves the syslog facility and logs a message that the data service has been started, as follows:
SYSLOG_FACILITY=`scha_cluster_get -O SYSLOG_FACILITY`
...
if [ $? -eq 0 ]; then
logger -p ${SYSLOG_FACILITY}.err \
-t [$SYSLOG_TAG] \
"${ARGV0} HA-DNS successfully started"
fi
|
See the scha_cluster_get(1HA) man page for more information.
Obtaining Property Information
Most callback methods need to obtain information about resource and resource type properties of the data service. The API provides the scha_resource_get() function for this purpose.
Two kinds of resource properties, system-defined properties and extension properties, are available. System-defined properties are predefined whereas you define extension properties in the RTR file.
When you use scha_resource_get() to obtain the value of a system-defined property, you specify the name of the property with the -O parameter. The command returns only the value of the property. For example, in the sample data service, the Monitor_start method needs to locate the probe program so it can launch it. The probe program resides in the base directory for the data service, which is pointed to by the RT_BASEDIR property, so the Monitor_start method retrieves the value of RT_BASEDIR, and places it in the RT_BASEDIR variable, as follows.
RT_BASEDIR=`scha_resource_get -O RT_BASEDIR -R $RESOURCE_NAME -G \ $RESOURCEGROUP_NAME` |
For extension properties, you must specify with the -O parameter that it is an extension property and supply the name of the property as the last parameter. For extension properties, the command returns both the type and value of the property. For example, in the sample data service, the probe program retrieves the type and value of the probe_timeout extension property, and then uses awk to put the value only in the PROBE_TIMEOUT shell variable, as follows.
probe_timeout_info=`scha_resource_get -O Extension -R $RESOURCE_NAME \
-G $RESOURCEGROUP_NAME Probe_timeout`
PROBE_TIMEOUT=`echo $probe_timeout_info | awk '{print $2}'`
|
- © 2010, Oracle Corporation and/or its affiliates