topic Re: customer_defined_run_cmds{} in Operating System - HP-UX

customer_defined_run_cmds{}

Hanry Zhou — Sun, 30 Jun 2002 23:45:55 GMT

Hi,

Can anybody please let me know a few examples as for what exactly the function needs to include to run when the package is started up?

Roger

Re: customer_defined_run_cmds{}

RAC_1 — Sun, 30 Jun 2002 23:51:42 GMT

Roger,

These are basically command/functions/programs
you would run before the package is started.

Say you have configured database in cluster and want to check some services - like monitoring, listener then you can such stuff here.

Regards,

Re: customer_defined_run_cmds{}

A. Clay Stephenson — Mon, 01 Jul 2002 00:10:54 GMT

The most common use is for commands which monitor the health of a given package.

Re: customer_defined_run_cmds{}

melvyn burnard — Mon, 01 Jul 2002 06:47:36 GMT

This is wher eyou would call your own scripts to run your application etc.
Here is an example of starting/stopping a web servre:

function customer_defined_run_cmds
{
# ADD customer defined run commands.
/opt/hpwebsuite/ns-enterprise/https-hpwing72/start
/opt/hpwebsuite/ns-enterprise/start-admin

test_return 51
}
# This function is a place holder for customer define 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.
/opt/hpwebsuite/ns-enterprise/https-hpwing72/stop
/opt/hpwebsuite/ns-enterprise/stop-admin
test_return 52
}
# END OF CUSTOMER DEFINED FUNCTIONS

Re: customer_defined_run_cmds{}

Duncan Edmonstone — Mon, 01 Jul 2002 08:40:50 GMT

The important points to mention in the customer_defined_run_cmds{} section is that, the last command before the call to test_return *must* return 0 if the application has started OK, and non-zero if it didn't. So for example if you have a routine that starts you database called start_db.sh which returns 0 on success and 1 on failure you could just do:

function customer_defined_run_cmds
{
# ADD customer defined run commands.
start_db.sh
test_return 51
}

BUT if your routine didn't return any meaningful return code then perhaps you might want to have another routine that checks the DB started and returned 0 on success:

function customer_defined_run_cmds
{
# ADD customer defined run commands.
start_db.sh
check_db_is_up.sh
test_return 51
}

HTH

Duncan

Re: customer_defined_run_cmds{}

Hanry Zhou — Mon, 01 Jul 2002 14:14:32 GMT

Melvyn, Duncan, and others,

1. Can I start up my applications, ex, start_db.sh in Serivce script, and also monitor these applications in it too.

2. Why alway return 51, which indicate some errors based on the test_return() function. As Duncan said, you only return non-zero, if you have problem with customer_defined_run_cmds{} function.

Please advice, and points will be assigned.

thanks,
Roger

Re: customer_defined_run_cmds{}

Sanjay_6 — Mon, 01 Jul 2002 14:17:30 GMT

Hi,

The commands run under this procedure are the ones required to execute / monitor etc for the package application you have configured. These can be anything related to the application package you want to run when the package is starting.

Hope this helps.

Regds

Re: customer_defined_run_cmds{}

Duncan Edmonstone — Tue, 02 Jul 2002 11:23:14 GMT

Roger,

To answer your two questions:

1. Yes you can do this - the great thing about MCSG is that cos large parts of it are based on shell scripts, its easy to change to suit your particular needs. However just because you *can* doesn't mean you *should*. Here's an extract from my MCSG cookbook:

/start quote/

Where Do I Start the Package?

There are two main schools of thought on how to configure application startup and shutdown within a package. These can be broadly summarized as follows:

?? The application is started through a Service. When the service exits because of application failure, starting the service again restarts the application. The customer_defined_run_cmds function in the package control file is left empty.
?? The application is started from a script defined in the customer_defined_run_cmds function in the package control file. Services monitor components of the application, and attempt to restart any failed component before exiting up to the service restart value. Once the service restart value is reached, the monitor just exits rather than attempting a restart, and ServiceGuard handles package failover to another node.

Both of these approaches are equally viable, but I find the second approach to be more flexible, and allow for additional granularity in terms of application components.

/end quote/

2. I think your misunderstaning the test_return function - the 'test_return 51' and 'test_return 52' aren't saying 'test the value of the return code and the value is 51 or 52' The 51 and 52 are used to tell the control script what to do if the value of $? (the return code from the last command is not zero). Take a look further down your control script and you will find this code fragment:

if (( $? != 0 ))
then
case $1 in
/...snip.../
51)
print "\tERROR: Function customer_defined_run_cmds"
print "\tERROR: Failed to RUN customer commands"
halt_services
customer_defined_halt_cmds
disown_dtc
remove_ip_address
umount_fs
deactivate_volume_group
exit 1
;;

52)
print "\tERROR: Function customer_defined_halt_cmds"
print "\tERROR: Failed to HALT customer commands"
exit_value=1
;;

Hope this makes more sense now.

HTH

Duncan