Specifications

Alarm Processing
Defining additional scripts for the sendevent alarming functionality is optional. When you define
LifeKeeper resources, LifeKeeper provides the basic alarming functionality described in the
processing scenarios later in this chapter.
Note: Local recovery for a resource instance is the attempt by an application under control of
LifeKeeper to return interrupted resource services to the end-user on the same system that generated
the event. Inter-server recovery allows an application to migrate to a backup system. This type of
recovery is tried after local recovery fails or is not possible.
Alarm Processing
Applications or processes that detect an event which may require LifeKeeper attention can report the
event by executing the sendevent program, passing the following arguments: respective error class,
error name and failing instance. Refer to the sendevent(5) manual pages for required specifics and
optional parameters and syntax.
Alarm Directory Layout
The /opt/LifeKeeper/events directory has two types of content:
l LifeKeeper supplied classes. LifeKeeper provides two alarm classes listed under the events
directory: lifekeeper and filesys. An example of an alarm event includes diskfull. The alarm
classes correspond to the strings that are passed with the -C option to the sendevent
command and the alarm events correspond to the strings that are passed with the -E option.
The lifekeeper alarm class is used internally by LifeKeeper for event reporting within the
LifeKeeper subsystem.
l Application-specific classes. The other subdirectories in the events directory are added
when specific applications require alarm class definitions. Applications register to receive
these alarms by placing shell scripts or binary programs in the directories. These programs are
named after the application package to which they belong.
Maintenance Tasks
The following are tasks for maintaining LifeKeeper.
Changing LifeKeeper Configuration Values
There are a number of values in LifeKeeper that may need to be changed after LifeKeeper has been
configured and set up. Examples of values that may be modified include the uname of LifeKeeper
servers, comm path ip addresses, ip resource addresses and tag names. To change these values,
carefully follow the instructions below.
1. Stop LifeKeeper on all servers in the cluster using the command:
/etc/init.d/lifekeeper stop-nofailover
There is no need to delete comm paths or unextend resource hierarchies from any of the
servers.
SteelEye Protection Suite for Linux201