%LKROOT%\bin\sendevent -C class-of-event -E event -m monitor-name -nname-of-obj-inst [-s severity]


The event notification facility consists of two parts: an event notification mechanism (%LKROOT%\bin\sendevent) and an application registration environment. Applications wishing to use the event facility should ”register” to get notification of specific events or alarms (or all occurrences of event/alarms).

The sendevent command is a program invoked by a daemon monitor process when the monitor has detected an event (failure or recovery) in the objects that it is monitoring. This command is not intended to be run directly at the shell level by a regular user or by a system administrator (only by a daemon process or another command).

The sendevent command is used to notify a ”registered” application of the occurrence of an event. For example, an application may want to be notified of an impending system shutdown so it can appropriately save files and data; or, in a client-server environment, the application may need to reconfigure itself to an alternate service provider. The application is responsible for providing the appropriate command support to handle the event.

The sendevent command passes all of its options to the event-response commands of the application.

An application registers to receive notification of events or alarms by installing its event-response commands in a specific registration directory, %LKROOT%\events. This should be done at application installation time. The events under %LKROOT%\events are further categorized in classes of events. Create separate subdirectories, genclass (for general events) and allclass to be used by applications to register to be notified upon occurrence of any event.

Each class directory contains a subdirectory for each event within that class. Each add-on package that monitors events and uses this event notification mechanism documents events it monitors and supports.

It is the responsibility of the application object monitor package to maintain a file called ACTIVE in the events subdirectories. If the ACTIVE file exists, it is a signal to the applications that a monitor is currently actively running and monitoring its objects for that specific event. If the package containing the monitor program is removed, the files named ACTIVE for the affected monitored events are removed too (by the package remove script) to indicate to applications that the event is no longer being monitored. The removal of the package should not remove event-response commands or event directories even if they are empty.

For those applications that may depend upon standard commands from another application, the application registration environment provides other application-specific directories, %LKROOT%\subsys\application-name\actions, for applications to place ”sharable” action commands. For example, application X may depend upon application Y being up and running after an event recovery. If this is not the case, application X may invoke the start command for application Y from the LKROOT%\subsys\Y\actions\start directory. Interdependencies between applications must be resolved and specified by the application developers.

The -C (class of event), -E (event), -m (monitor name), and -n (name of object instance) options are required. If the -s (severity) option is not specified, sendevent will default to a severity of MAJOR alarm.

Upon invocation of the sendevent command by a monitoring process, sendevent determines which event class and event has occurred based upon the arguments to the -C and -E options. The sendevent command executes in the background until it finishes processing all the event-response commands (if any) placed in the registration directory corresponding to that class/event pair and all of the commands registered in the all directory.

The following options are supported:

-C class-of-event

Events are grouped together into classes. This required option indicates which class the event belongs to.

-E event

This required option indicates which event in a class is being triggered.

-m monitor-name

Each application object monitor that can send alarms/events is identified by a name in the form:


OM-product-name is an ASCII string, of up to eight characters. It is an abbreviated identifier specifying the product that monitors the objects that cause alarms or events. OM-component-name is an ASCII string, of up to 16 characters. It is defined by the object monitor to identify the component of the object monitor that detected the alarm or event.

The monitor names are used to distinguish between different products that may be used to monitor the same object.

-n name-of-obj-inst

This option is used to name a specific instance of an application object. It is an ASCII string with a maximum length of 64 characters. For example, D: may be the name of a volume application object, whereas 1234 could be used to identify a specific process object.

-s severity

Each alarm or event must specify the severity of the problem it is reporting. If this option is not specified, sendevent internally adds the default severity for MAJOR alarm. Severity is an ASCII represented integer interpreted as follows:

0 CLEARED alarm specified by ”id-of-alarm/event” has been recovered
1 INFORMATIONAL alarm (INFO message or cmn_err() NOTICE message)
2 WARNING alarm (WARNING message)
3 MINOR alarm (MINOR message)
4 MAJOR alarm (MAJOR or ERROR message) (default)
5 CRITICAL alarm (CRITICAL message or cmn_err() PANIC or HALT message)


The output this command generates occurs in one of two conditions:

  • Error messages are printed to standard error and a nonzero exit code is returned.
  • The identifier for the alarm\event called id-of-alarm/event is printed to standard output at each call to sendevent.

Exit Codes

The following exit codes are returned by sendevent:

0 The sendevent command has completed successfully without errors.
1 Syntax error in the argument list.
2 No class corresponding to the string passed with the -C option exists in the %LKROOT%\events directory.
3 No event corresponding to the string passed with the -E option exists in the %LKROOT%\events\<class= directory.
4 The -A option is internally generated and may not be specified directly.
5 The -i option must be specified if the -s 0 (severity CLEARED) option is used.


Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment