Just to clarify some points here:
If you don't specify CleanProgram in application, then if you have used MonitorProcesses or PidFiles, then VCS will still clean (kill) these processes
You can't disable the monitor for an agent, but you can disable monitor for an application - what I mean is that you can specify the MonitorProgram attribute and NOT use MonitorProcesses and PidFiles and in your code you don't have to Monitor your application and you can monitor a lock file instead - for example:
App_Name=$2
LOCKFILE=/tmp/.{$App_Name}.DO_NOT_REMOVE
case "$1" in
start)
touch $LOCKFILE
# code to start app $App_name
stop)
# code to stop app $App_name
rm $LOCKFILE
;;
monitor)
if [ -a $LOCKFILE ]
then
exit 110
else
exit 100
fi ;;
*)
echo "Usage: $0 {start|stop|monitor} app_name lock_file
exit 1
;;
esac
So if you called this file app.sh and put it in /opt/VRTSvcs/bin, then you configure your app like:
Application app1 (
StartProgram = "/opt/VRTSvcs/bin/app.sh start app1"
StopProgram = "/opt/VRTSvcs/bin/app.sh stop app1"
MonitorProgram = "/opt/VRTSvcs/bin/app.sh monitor app1"
)
So this has no clean, and VCS knows nothing about the application so cannot clean it. But your customers main concern is probably that VCS does not interfere by cleaning resource, but IF the application resource has no dependent resources, you might at well do a proper monitor in the code above as this tells you the state of the App and then if you make the resource non-critical, if the App is down there is no clean to call and non-critical means service group does not fault, so basically in this config, VCS informs you app is down, but takes no action, which is probably what the customer wants so I would remove creation and removal of lock files and replace monitor code above with:
monitor)
# code to start app $App_name
if $App_name is UP
then
exit 110
else
exit 100
fi ;;
If you are considering using postonline, then I presume your app resource has no dependencies and is at the top of the dependency tree, but for resources that DO have dependencies, even if resource is non-critical, then if resource faults, then it brings down the resources above it, so if you don't want VCS to take action, there are some SERVICE GROUP attributes to stop cleaning resources - see extracts from VCS admin guide:
ManageFaults
Specifies if VCS manages resource failures within the service
group by calling the Clean function for the resources. This
attribute can take the following values.
NONE—VCS does not call the Clean function for any resource in
the group. User intervention is required to handle resource
faults.
And this is quite often use with the following attribute if the resource is not at the top of the tree
FaultPropagation
Specifies if VCS should propagate the fault up to parent
resources and take the entire service group offline when a
resource faults.
The value 1 indicates that when a resource faults, VCS fails over
the service group, if the group’s AutoFailOver attribute is set to 1.
If The value 0 indicates that when a resource faults, VCS does not
take other resources offline, regardless of the value of the
Critical attribute. The service group does not fail over on
resource fault.
However, as these are service group attributes, not resource attributes, they are generally used for Test/Dev service groups were you don't want VCS to take action for ANY resource. Asssuming you want VCS to react to other resource failures (Diskgroup, Mount, IP), then you would need to put resources in another dependent service group to use ManageFaults and FaultPropagation attributes.
You can use postonline and postoffline and the code in a postonline will look something like:
sys=$1
sg=$2
If $sg app1
then start app1
If $sg app2
then start app2
or if you have used good naming conventions for service group then:
app=`echo $sg | sed -e expression`
start $app
Mike
