Synopsis
perform_action [-G] [-s] [-b] [-n] -t tag-name -a action-name [- - arg1 arg2 . . . argn]
Description
The LRACI program perform_action performs processes in the following order:
- Finds the resource specified by the tag-name argument of the -t option.
- Finds the action script specified by the action-name argument of the -a option.
- Executes the action script on the tag-name resource instance.
The arguments after the -- argument are passed unchanged to the action script(s). These are arguments that the developer of the action may optionally require to use the action.
The perform_action program finds the action script by the following algorithm: it first searches in the actions directory for the resource type of the resource instance specified by tag-name:
%LKROOT%\subsys\appname\resources\restypname\actions\action-name.ksh
and if not there, it checks the actions directory of the application the resource instance belongs to:
%LKROOT%\subsys\appname\actions\action-name.ksh
The restore and remove actions are special cases for LRACI. The restore action moves an application hierarchy that may be in-service on the remote system to the local system. For restore, LRACI first checks to make certain that the resource instance tag-name is not already in the ISP state. If it is not, it recursively checks all of the resource instances that this resource depends upon. The check continues until a resource is found that either depends on no resources, or all of the resources it depends on are already in the ISP state. If the resource was in the ISU state,it is placed in the ISP state.
If the resource was in the OSU or OSF state, LRACI executes the remove script for any affected resources on the remote system. When this completes, LRACI finds the restore action using the above algorithm and runs it. If the script fails, the resource is placed in the OSF state and LRACI stops. If it succeeds, LRACI recursively ”restores” the resources up the tree, until the resource specified by tag-name is restored. Then the LRACI recursively checks and ”restores” the parent resource instances in a similar fashion until all related root resource instances are restored. In each case, LRACI uses the above algorithm to find the correct restore script using the resource application and resource type of the resource currently being scanned by LRACI, not the resource application and resource type of the tag-name resource.
For the remove action, the resources are moved recursively in the opposite direction. LRACI calls the remove script of all resources starting at the root resources that depend directly or indirectly on the tag-name resource down to, and including, the tag-name resource if any of those resources are in the ISP or ISU state. Resources not in the ISP or ISU state are ignored. If one of the remove scripts fails, LRACI places the failing resource into the OSF state and stops. In each case, LRACI uses the algorithm to find the correct remove script using the resource application and resource type of the resource currently being scanned by LRACI, not the resource application and resource type of the tag-name resource.
The remove and restore actions automatically have the -t tag-name and -i ident-field arguments added to the argument list that corresponds to the resource instance being acted upon.
The following sections discuss the arguments accepted by perform_action.
| -G | This option is only used if action-name is remove, restore, or delete. If this option is not specified, LRACI performs the preglobal and postglobal scripts before and after the actions are performed [ see lcdrecover in LCD ]. If the option is specified, LRACI does not run the preglobal and postglobal scripts. This option is useful if you need to run perform_action more than once, but you only want to run the preglobal and postglobal scripts once. It is also useful if you need to run perform_action while creating a resource hierarchy. The preglobal and postglobal scripts should not be run by perform_action during hierarchy create because the hierarchy creation scripts should be set up to obtain the ”admin lock flags” [ see LCDI_flag ] and postrestore also requires the ”admin lock flags” which would lead to contention problems. |
| -s | The default behavior for the restore action is to bring all objects above and below the specified tag into service, and the default behavior for the remove action is to bring all objects above the specified tag out of service. The -s option limits the scope of the operation to just the specified flag. |
| -b | The default behavior for the restore action is to bring all objects above and below the specified tag into service. The -b option changes this behavior to just objects below the specified tag. This option has no effect on the remove action. |
| -n | This option is only used if the action-name is remove or restore. If this option is specified, the resource reserves are not to be checked and the actions are performed whether the resources are reserved or not. WARNING: EXTREME CAUTION SHOULD BE TAKEN WHEN USING THIS OPTION! If this option is not specified, before any remove or restore scripts are executed, LRACI checks to see if any of the resources on which any of the actions will be run are currently reserved by another process. A resource can be reserved while the following operations are being performed on them: a resource ”remove from service” is in progress, a ”resource restore to service” is in progress, or a resource ”recovery” is in progress. If any resource is so reserved, LRACI waits a specified period of time for the process to remove the reserve on the resource. If that period expires, LRACI removes the reserve. In either case, LRACI reserves all of the resources, then follows the specified algorithm to perform the action(s). |
| -t tag-name | This is the last resource instance the action will be performed on. |
| -a action-name | This is the resource action that will be performed. |
| -- arg1 arg2 … argn | Argument(s) the resource action developer can optionally define to be passed to the action script. When executing perform_action within a getlocks protected region and the -G option is not used, set arg1 to -m to avoid executing a second instance of getlocks, which would cause the operation to hang. |
Example
The following is an example of calling an action:
perform_action -t SCSI-USR-DISK -a reset-heads — -h 7
The LRACI program perform_action would find the action corresponding to reset-heads and execute it with the arguments:
reset-heads -t SCSI-USR-DISK -h 7
Exit Codes
The following exit codes could be returned by LRACI:
| 0 | The operation has succeeded. |
| 1 | A system call or library call has internally returned failure. |
| 2 | A user-specified syntax error occurred. |
| 3 | LifeKeeper internal error. |
| 4 | A request to perform an operation on an object that already exists. |
| 5 | An argument specified is illegal. |
| 6 | Index out-of-range. |
| 7 | A request has been made on an object that does not exist. |
| 8 | A request was made to delete a resource instance on which another non-deleted resource instance depends. |
| 9 | An attempt to communicate with another system failed. |
Post your comment on this topic.