openipmi_eventd(1)

💖 openipmi_eventd — bestie edition 💖

okay so this is openipmi_eventd, the IPMI event handler from the OpenIPMI crew, and it is literally the girl in the group chat who relays messages. She sits there, listens for IPMI events, and then hands them off to another program to deal with — or just dumps them in a file. no cap. 🦋

✨ NAME ✨

openipmi_eventd — An IPMI event handler. that's it, that's the vibe. 👑

🎀 SYNOPSIS 🎀

openipmi_eventd <domain name> <connection parms> <options> <program>
[<parm1> [<parm2> [...]]]

🌸 DESCRIPTION 🌸

The openipmi_eventd program listens for IPMI events on the given connection, and then sends them off to another program to process — or, if that's more your thing, to a file. it's giving event relay main character energy, and honestly? obsessed. 💅

🫶 PARAMETERS 🫶

• <domain name> — the name to use for the OpenIPMI domain. this shows up in logs and in some names, so pick something cute (or at least something you'll recognize later). ✨
• <connection parms> — the parameters for the connection depend on the connection type, bestie. they're all described over in openipmi_conparms(7). go read that one, i'll wait. 🍓
• <options> — zero or more of the options defined down in OPTIONS. yes, zero is allowed. she's flexible like that. 💜
• <program> [<parm1> [<parm2> [...]]] — the program to run. this must be the full path to the program, no shortcuts, no vibes-based guessing. any given parameters are passed to the program before any IPMI parameters. order matters, bestie. 🔥

💅 OPTIONS 💅

• -f filename, --outfile filename — send all events to the given file. just, like, all of them. 💌
• -k, --exec-now — immediately spawn the given program and send the event information to that program's standard input. the program should not quit — if it does, then this program will exit with an error. so like, keep it alive, girl. 😭
• -i, --event-stdin — send the event information to the program's standard input instead of the commandline. a whole different delivery method, iconic. 🎀
• -e, --delete-events — delete events from the SEL (System Event Log) once they have been processed. note that the program has to have handled the event without error for the event to be deleted — otherwise the events are not deleted from the SEL. so if your handler fumbles it, nothing gets cleaned up. periodt. 💀
• -b, --dont-daemonize — do not daemonize the program, run it as a foreground process. she stays right there where you can see her. 👀
• -d, --debug — debug the program, turn on output, send all logs to stderr, and do not run the process as a daemon. this is the "spill all the tea" mode. 🌈

🌟 USAGE 🌟

When started, this program will connect to the given IPMI domain, ignore all existing logs, and set up to listen for logs from all sources. when an event comes in, it'll handle the event depending on how it is configured. 💫

By default, the program will be called on each log and the event information passed on the program's command line. The first parameter (after the ones given on the openipmi_eventd command line) will be the event type, and the rest are key-value pairs as defined below. 🔑

If -i is given on the commandline, instead of passing in the event information on the command line, it will be passed into the program's standard input. The first line will be the event type, and each line will have a key-value pair up until the last line, which will be endevent. ✨

If -k is given on the command line, the program will be started immediately and expected to take events on its standard input as they come in. Each event will start with an event type, contain key-value pairs, and end in endevent. 🎧

🦋 EVENT KEY-VALUE PAIRS 🦋

The first line and parameter of an event is always the event type — either threshold, discrete, or unknown. Then the following, in no particular order. When sending to a file, or to another program via standard input, endevent will mark the end of an event. 🏁

• assert true|false — if true, the event is being asserted (the alarm is present). if false, the alarm was present but has now gone away. she left. 🙈
• eventtype <num> — the event type, per the IPMI specification. 📖
• eventtime <num> — the time (in seconds) for the IPMI event. it is 64 bits. big number energy. ⏰
• eventdata <vals> — the raw event data; vals is a list of hex numbers. 🔢
• id <name> — the OpenIPMI id of the sensor. this is in the format: <entity_id>.<entity_instance>.<sensor_name>, where the entity id and instance identify the object being monitored and the sensor name comes from the sensor. only for discrete and threshold events. 🏷️
• val <floatnum> — the sensor value that caused the event, in floating point format. optional, and only present for threshold sensors. 🌊
• raw <hexnum> — the sensor value that caused the event, in raw (hex) format. optional, and only present for threshold sensors. 🧮
• off <num> — the bit in the sensor that caused the event. only present for discrete sensors. 📍
• severity — the severity of the event. for discrete sensors this is optional and is a number between 0 and 14. the meaning depends on the specific sensor type. for threshold sensors this is one of:
  • lower_non_critical
  • lower_critical
  • lower_non_recoverable
  • upper_non_critical
  • upper_critical
  • upper_non_recoverable
• prevseverity — for discrete sensors. that's the whole description bestie, i don't make the rules. 💀
• direction — the direction of the event, only for threshold sensors. this can be difficult to understand and is not consistent on IPMI systems. the IPMI specification does define what this means. for instance, what does an assertion of an upper critical event going low mean? yeah. ponder that. 🤔

👑 SEE ALSO 👑

openipmi_conparms(7) — go read it, it's the prequel. 📚

💜 KNOWN PROBLEMS 💜

None. she's flawless, your honor. ✨

🎀 AUTHOR 🎀

Corey Minyard <cminyard@mvista.com> — the icon, the legend, the moment. 🫶

and that's the whole page, bestie!! this came to you from OpenIPMI, dated 03/4/15 — go forth and relay those events. slay, stay daemonized (or don't, -b exists), and remember: no cap, endevent marks the end. 💖✨🌈