The Event Manager collects event information from other applications. It runs independently of all other applications and enables local or remote applications to receive event data from it on a subscription basis.
The Event Manager uses a producer/consumer architecture (refer to Figure 1-1).
Applications that create events and send them to the Event Manager are called producer applications (or producers). Applications that subscribe to receive event information from the Event Manager are called consumer applications (or consumers). Producers and consumers can reside on the same system as the Event Manager or on remote systems.
When the Event Manager registers an event from a producer application, it forwards the event information to all consumer applications that are subscribed to receive information about the event. Those applications must include functionality to process the event because the Event Manager simply forwards the event information that it receives; the Event Manager does not process the event information.
The Event Manager runs as a daemon (eventmond) that starts at system startup and waits to receive events from producer applications and send event information to consumer applications. You can also manually run eventmond to send commands to the daemon through secured UNIX domain sockets.
Event management uses the following components (refer to Figure 1-2):
Event manager
Event producer
Event subscriber
Event consumer
Event manager application programming interface (API)
Note: A single application can combine any or all of the event subscriber, producer, and consumer functions.
The Event Manager is a multi-threaded UNIX process that normally runs at system startup as a daemon (eventmond) and monitors TCP/IP port 5553 for events from producers and subscription/unsubscription requests from subscribers. When the Event Manager detects an event, it forwards the event information to all local and remote consumers that are subscribed to the event. The Event Manager discards any events that are not subscribed to a consumer.
You can use the eventmond command to configure the daemon and control tasks that it runs. (Refer to Chapter 4, “eventmond Command-line Options”, for more information)
| Note: This new version of eventmond replaces the version of eventmond that shipped with earlier versions of IRIX. It is named eventmond to provide compatibility with older versions of IRIX. |
An event producer is an application that creates events and sends them to the Event Manager via the Event Manager API. There are two types of event producer applications:
A separate process that runs on the local system or on a remote system.
A shared library (also called a dynamic shared object [DSO]) that the Event Manager loads and executes.
Example event producers include the syslog DSO and the availmon and configmon standalone applications.
An event subscriber is a special subscription management application. It subscribes a consumer to an event so the consumer can receive event information from the Event Manager. It unsubscribes the consumer from the event when the consumer no longer requires information about the event.
An example event subscriber is espconfig, which handles event subscription for Embedded Support Partner (ESP) version 3.0.
| Note: Event subscriber functions can also be contained in producer or consumer applications. |
An event consumer is an application that subscribes to receive events and then processes the event data that it receives. There are four types of event consumer applications:
A shared library consumer is a compiled function that is linked in a shared library that the Event Manager can dynamically load into its address space and then execute. The Event Manager passes the event as a parameter to the function. You must specify the name of the shared library and the function that you want to call in the shared library when you subscribe the consumer to the event. If the shared library is not in a standard library directory (for example, /usr/lib), you must specify the full path to the shared library when you subscribe the consumer.
An executable consumer can be any type of executable file that the Event Manager can execute with a fork()/exec() sequence. If the executable file is not accessible through the PATH environment variable, you must specify the full path to the file when you subscribe the consumer.
A shared memory executable consumer is an application that can access the event information directly from memory that is shared with the Event Manager. The Event Manager sends the consumer a command-line parameter that specifies a key which indicates where the consumer can access the event information.
A forwarding consumer is a feature of the Event Manager that simply forwards the event to another application. It does not process the event.
Consumers must subscribe to events with the Event Manager to receive information about the events that occur. Consumers should unsubscribe from events when they no longer need to receive the event information. Event subscription and unsubscription is normally performed by a subscriber application, but it can be performed by a producer, consumer, or subscriber application.
An example event consumer application is the Embedded Support Partner consumer DSO that processes all events for ESP by logging the events and performing actions assigned to them.
The Event Manager application programming interface (API) contains a set of functions that enable other applications to communicate with the Event Manager. Event producers send information to the Event Manager via the Event Manager API. Event handlers (consumers) receive event information via the Event Manager API.
Subscriber applications use the Event Manager API to manage the event subscription/unsubscription process for consumers. The API also enables applications to access information within an event.
The API library is dynamically linked to the applications.
Refer to Chapter 2, “Event Manager API”, for descriptions of the Event Manager API functions.