Normally, offline processing results in the userApplication object transitioning to the Offline state.
An offline request can be generated for any of the following reasons:
Manual offline request using the GUI or CLI (hvutil -f)
Manual switch request using the GUI or CLI (hvswitch)
Offline processing after a fault, either automatically or using the GUI or CLI (hvutil -c)
RMS shutdown using the GUI or CLI (hvshut)
In normal operating mode, only the RMS command interface can generate an Offline request. In the case of a fault, the userApplication generates its own Offline request to prevent an application that is no longer operating correctly from continuing to operate in an uncontrolled manner (see also the "2.1.5 Fault processing"). This offline request is also a primary precondition for any subsequent switchover.
Note
Offline processing of userApplication objects does not occur if RMS is shut down with 'hvshut -L' or 'hvshut -A'.
Unlike online processing, the direction of offline processing is from the userApplication to the leaf object (top-down). Nodes without a detector execute the post-offline script immediately after the offline script. The offline process is as follows:
The userApplication changes to the Wait state.
The userApplication executes its pre-offline script, and sends a corresponding request to its children after the pre-offline script terminates.
After receiving the pre-offline request, each child object changes to the Wait state, executes its pre-offline script, and forwards the request.
As soon as the leaf objects have completed their pre-offline script, they send a corresponding message (confirmation of successful pre-offline processing) to their parents.
The message is forwarded without any further activity from the children to the parent until it arrives at the userApplication.
After pre-offline processing has been completed, the userApplication executes its offline script, immediately followed by the post-offline script (userApplication is a object without a detector).
The userApplication then generates the actual offline request.
Processing of the offline request in the individual objects is similar to online processing, as follows:
The offline script is executed first.
The post-offline script is started after the object's detector Offline report has arrived.
After the post-offline script has completed, the offline request is forwarded to each of the object's children.
When all children have returned a PostOfflineDone message, the object returns a PostOfflineDone message to its parent.
As illustrated, the userApplication is the final object to go offline. After the last child returns a PostOfflineDone message, the offline processing is complete; the OfflineDoneScript, if present, is fired; and the base monitor notifies the corresponding userApplication objects on the other nodes that the application has gone offline.
Example 3
The following further explains the offline process:
As none of the objects in the example has a pre-offline script, the corresponding pre-offline request is forwarded from app down to the leaf object.
The leaf object returns a success message to the userApplication.
The userApplication executes its offline script; in our example, this means that the application app is stopped. As the object app does not monitor the application, RMS considers the successful completion of the offline script to be a successful completion of offline processing.
A post-offline script is not configured, and an offline request is accordingly sent to andOp1 immediately after the offline script has completed.
The andOp1 object has no detectors and no scripts. The offline request is simply permitted to pass through.
The cmd object executes its offline script and forwards the request as soon as its own detector signals that offline processing has completed successfully.
The lfs leaf object also executes its offline script and forwards the success message after the corresponding report of its detector.
Offline processing completes successfully when app receives the success message.
Upon successful completion of offline processing, the OfflineDoneScript is fired. This script is intended for cleanup or for sending information. Its return code has no impact on the state of the userApplication.
Unexpected reports during offline processing mean reports which are reported during the offline processing but not in the Offline state ignored by the base monitor.
Reports other than in the Offline state ignored by the base monitor may be reported from the point where the offline processing of the user application which an object belongs to starts until the object's offline processing succeeds or fails.
For cases where the object's offline processing fails, see the "2.1.4.4 Fault situations during offline processing".
If an error situation occurs during offline processing, the affected object commences fault processing and notifies its parent of the error (see also the "2.1.5 Fault processing"). The following can cause faults during offline processing:
When the last reported state from a detector of a resource object is in the Online, Standby, or Faulted state at the point where Offline processing finishes.
Script fails with an exit status other than 0.
Script fails with a timeout.
An object's OfflineScript finishes and the detector does not notify the Offline state within a specific period.
An object may already be offline at the start of offline processing. This typically occurs if an offline request originates from a host where the parent userApplication is offline. (If the parent userApplication is online, then the offline object must be in the tree below an OR object.) When an offline object receives an offline request, the request is merely passed through, similar to the situation in online processing. Scripts are not executed, and the Wait state is not entered.
RMS covers an extremely wide range of system conditions, including monitoring resources that cannot be taken to the Offline state by a script. Physical disks are an example of such objects because they are monitored but cannot in general be physically shut down. For this purpose, RMS provides the attribute LieOffline to indicate that the resource has no true Offline state. The Wizard Tools subapplications set this attribute by default for gResource objects that represent physical disks, so it does not have to be explicitly specified.
During offline processing, an object whose LieOffline attribute is set reacts in the same way as any other object when its preoffline, offline, and postoffline scripts are run. The reaction of the object with respect to its parent is also the same as if the object had been successfully taken offline; that is, it "lies." An object with LieOffline set does not wait for an offline report of the detector after the offline script has executed; instead, it automatically executes the post-offline script. An unexpected online report of the detector (which arrives after the offline script has executed) is not a fault condition in this case.
