scha_control(1HA)

NAME

scha_control– request resource group control

SYNOPSIS

scha_control-Ooptag-Ggroup-Rresource

DESCRIPTION

The scha_control command requests the restart or
relocation of a resource group that is under the control of the Resource Group
Manager (RGM) cluster facility. The command is intended
to be used in shell script implementations of resource monitors. It provides
the same functionality as the scha_control(3HA)
C function.

The exit code of the command indicates whether the requested action
was rejected. If the request is accepted, the command does not return until
the resource group or resource has completed going offline and back online.
The fault monitor that called scha_control(1HA)
might be stopped as a result of the group going offline and so might never
receive the return status of a successful request.

OPTIONS

The following options are supported:

-Ggroup

The name of the resource group that is to be restarted or
relocated. If the group is not online on the node where the request is made,
the request is rejected.

-Ooptag

Request optag options.

The following optag values are supported:

RESTART

request
that the resource group named by the -G option be brought
offline, then online again, without forcing relocation to a different node.
The request may ultimately result in relocating the resource group if a resource
in the group fails to restart. A resource monitor using this option to restart
a resource group can use the NUM_RG_RESTARTS query of scha_resource_get to keep count of recent restart attempts.

RESOURCE_RESTART

request that the resource named by the -R option be brought
offline and online again on the local node without stopping any other resources
in the resource group. The resource is stopped and restarted by applying the
following sequence of methods to it on the local node:

MONITOR_STOP
STOP
START
MONITOR_START

If the resource's type does not declare a MONITOR_STOP
and MONITOR_START method, then only the STOP
and START methods are invoked to perform the restart. If
the resource's type does not declare both a START and STOP method, scha_control fails with exit code
13 (SCHA_ERR_RT).

If a method invocation fails while restarting the resource, the RGM
might either set an error state, relocate the resource group, or reboot the
node, depending on the setting of the Failover_mode property
of the resource. For additional information, see the Failover_mode property in r_properties(5).

A resource monitor using this option to restart a resource can use the NUM_RESOURCE_RESTARTS query of scha_resource_get
to keep count of recent restart attempts.

The RESOURCE_RESTART function should be used with
care by resource types that have PRENET_START and/or POSTNET_STOP methods. Only the MONITOR_STOP, STOP, START, and MONITOR_START
methods will be applied to the resource. Network address resources on which
this resource implicitly depends will not be restarted and will remain online.

RESOURCE_IS_RESTARTED

request that the resource restart counter for the resource named by
the -R option be incremented on the local node, without actually
restarting the resource.

A resource monitor that restarts a resource directly without calling
the RESOURCE_RESTART option of scha_control,
(for example, using pmfadm(1M)), can
use this option to notify the RGM that the resource has been restarted. This
will be reflected in subsequent NUM_RESOURCE_RESTARTS queries
of scha_resource_get.

If the resource's type fails to declares the Retry_interval standard property, the RESOURCE_IS_RESTARTED
option of scha_control is not permitted and scha_control returns exit 13 (SCHA_ERR_RT).

GIVEOVER

request
that the resource group named by the G option be brought
offline on the local node, and online again on a different node of the RGM's choosing. Note that, if the resource group is currently online
on two or more nodes and there are no additional available nodes on which
to bring the resource group online, it may be taken offline on the local node
without being brought online elsewhere. The request may be rejected depending
on the result of various checks. For example, a node might be rejected as
a host because the group was brought offline due to a GIVEOVER
request on that node within the interval specified by the Pingpong_interval
property.

In addition, the resources in the group might contain MONITOR_CHECK callback methods that the RGM invokes in the
event of a giveover request. These methods verify that a node is healthy enough
to run the resource. For example, a MONITOR_CHECK method
might verify that an essential configuration file is available on the node,
and if it isn't, veto the giveover request.

CHECK_RESTART

perform all the same validity checks that would be done for a RESTART of the resource group named by the -G option, but
do not actually restart the resource group.

CHECK_GIVEOVER

perform all the same validity checks that would be done for a GIVEOVER of the resource group named by the -G option, but
do not actually relocate the resource group.

The CHECK_GIVEOVER and CHECK_RESTARToptags are intended to be used by resource
monitors that take direct action upon resources (for example, killing and
restarting processes, or rebooting nodes) rather than invoking scha_control
to perform a giveover or restart. If the check fails, then the monitor should
sleep for awhile and restart its probes rather than invoke its restart or
failover actions. For more information, see scha_control(3HA).

-Rresource

The name of a resource in the resource group. Presumably the
resource whose monitor is making the scha_control(1HA)
request. If the named resource is not in the resource group, the request is
rejected.