networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
2.08k stars 351 forks source link

ApcUpsD like Events ? #1041

Open FrankBKK opened 3 years ago

FrankBKK commented 3 years ago

I am writing a client that handles NUT and apcupsd protocols.

Apcupsd command EVENTS provides logged messages in the form n( timestamp + message + LF ) + EOF

Does NUT log such events as well and has a similar command to access them ?

LIST VAR server gives me only the status information but no actual events like power failures, daemon start/stop etc.

jimklimov commented 1 year ago

Sorry for the late reply, just noticed this on a random walk through issues :\

As you may know by now, https://github.com/networkupstools/nut/blob/master/docs/net-protocol.txt describes the networked protocol which NUT does have, as served by the data server upsd (as one of numerous daemons generally involved in a NUT setup). I am not aware of any of those tracking their start/stop events, times or general uptime - relegating that to the OS for whose curious to know (at least about daemon start/stop logging).

Probably some info can be added to driver.* namespace so daemons would report since when/how long they are running as part of data dumps (upsc et al), can't quickly think up an existing backwards-compatible spot for similar info from other daemons. If there is a need or otherwise nifty idea, protocol expansion proposals can be discussed on the NUT mailing lists with the rest of community - more so now that there is an RFC based on that, and adding a PUB/SUB pattern or similar would be a big undertaking to consider carefully. This idea may be somewhat related to another #1703 however.

While there is some regular chatter on a socket/pipe protocol between upsd and locally running driver(s) represented by it on the network, to update information, probe driver staleness, etc., the data server does not generally inform networked clients of everything that happens and is mostly oriented at one or few request-replies per session (nowadays with encouraged TRACKING support to map questions to answers reliably), with various clients being interested in different things (data, devices...) based on their current role.

There are provisions for "logged-in" clients like upsmon -- note the discussion of LOGIN <UPS> command, that it's primarily intended for counting the clients powered by a particular UPS that this data server represents; it would rely on USERNAME and PASSWORD to succeed earlier in the session, and on settings of that user in upsd.users file.

However even so, the upsmon client runs a polling loop to learn about power states and estimate criticality of the situation from devices it monitors, one at a time. There are OS signals (like user/script running upsmon -c fsd) but no events pushed by the server "urgently", I think: https://github.com/networkupstools/nut/blob/b6dffef/clients/upsmon.c#L2753-L2756