1openipmi_eventd(1) IPMI event handler openipmi_eventd(1)
2
6 openipmi_eventd - An IPMI event handler
7
10 openipmi_eventd <domain name> <connection parms> <options> <program>
11 [<parm1> [<parm2> [...]]]
12
14 The openipmi_eventd program listens for IPMI events for the given con‐
15 nection and sends them to another program to process, or to a file.
16
19 <domain name>
20 The name to use for the OpenIPMI domain. This will appear in
21 logs and some names.
22 <connection parms>
25 The parameters for the connection depend on the connection type.
26 These are all described in openipmi_conparms (7)
27 <options>
30 Zero or more of the options defined in OPTIONS below.
31 <program> [<parm1> [<parm2> [...]]]
34 The program to run. This must be the full path to the program.
35 Any given parameters are passed to the program before any IPMI
36 parameters.
37
40 -f filename, --outfile filename
41 Send all events to the given file
42 -k, --exec-now
45 Immediately spawn the given program and send the event informa‐
46 tion to that program's standard input. The program should not
47 quit, if it does then this program will exit with an error.
48 -i, --event-stdin
51 Send the event information to the program's standard input
52 instead of the commandline.
53 -e, --delete-events
56 Delete events from the SEL (System Event Log) once they have
57 been processed. Note that the program has to have handled the
58 event without error for the event to be deleted. Otherwise the
59 events are not deleted from the SEL.
60 -b, --dont-daemonize
63 Do not daemonize the program, run it as a foreground process.
64 -d, --debug
67 Debug the program, turn on output, send all logs to stderr, and
68 do not run the process as a daemon.
69
72 When started, this program will connect to the given IPMI domain,
73 ignore all existing logs, and set up to listen from logs from all
74 sources. When an event comes in, it will handle the event depending on
75 how it is configured.
76 By default the program will be called on each log and the event infor‐
78 mation passed on the program's command line. The first parameter (after
79 the ones given on the openipmi_eventd command line) will be the event
80 type, the rest are key-value pairs as defined below.
81 If -i is given on the commandline, instead of passing in the event
83 information on the command line, it will be passed into the program's
84 standard input. The first line will be the event type, and each line
85 will have a key-value pair up until the last line, which will be ende‐
86 vent.
87 If -k is given on the command line, the program will be started immedi‐
89 ately and expected to take events on its standard input as they come
90 in. Each event will start with an event type, contain key-value pairs,
91 and end in endevent.
92
95 The first line and parameter of an event is always the event type
96 (either threshold , discrete , or unknown ). Then the following then
97 the following, in no particular order. When sending to a file, or
98 another program via standard input, endevent will mark the end of an
99 event.
100 assert true|false
103 If true, the event is being asserted (the alarm present).
104 If false, the alarm was present but has now gone away.
105 eventtype <num>
107 The event type, per the IPMI specification.
108 eventtime <num>
110 The time (in seconds) for the IPMI event. It is 64 bits.
111 eventdata <vals>
113 The raw event data, vals is a list of hex numbers.
114 id <name>
116 The OpenIPMI id of the sensor. This is in the format:
117 <entity_id>.<entity_instance>.<sensor_name> where the
118 entity id and instance identify the object being moni‐
119 tored and the sensor names comes from the sensor. Only
120 for discrete and threshold events.
121 val <floatnum>
123 The sensor value that cause the event, in floating point
124 format. Optional and only present for threshold sensors.
125 raw <hexnum>
127 The sensor value that cause the event, in raw (hex) for‐
128 mat. Optional and only present for threshold sensors.
129 off <num>
131 The bit in the sensor that caused the event, only present
132 for discrete sensors.
133 severity
135 The severity of the event. For discrete sensors this
136 optional and is a number between 0 and 14. Them meaning
137 depends on the specific sensor type. For threshold sen‐
138 sors this is one of:
139 lower_non_critical
141 lower_critical
143 lower_non_recoverable
145 upper_non_critical
147 upper_critical
149 upper_non_recoverable
151 prevseverity
153 for discrete sensors.
154 direction
156 The direction of the event, only for threshold sensors.
157 This can be difficult to understand and is not consistent
158 on IPMI systems. The IPMI specifiation does define what
159 this means. For instance, what does an assertion of an
160 upper critcal event going low mean?
161
164 openipmi_conparms(7)
165
168 None
169
172 Corey Minyard <cminyard@mvista.com>
173OpenIPMI 03/4/15 openipmi_eventd(1)