upsmon: on a busy system may erroneously log waking up from hibernation

[jimklimov]

Seen on Raspberry Pi with a PiJuice HAT which is a NUT CI farm build node, sometimes correlates with COMMBAD/COMMOK and/or ONLINE/ONBATT messages.

Maybe some wrong reply is seen from systemd inhibitor interface, or an RTC clock sync made a jump? There are journal messages timestamped seemingly consistently before and after this notification, and no indication of a real hibernation.

Seems to be practically inconsequential for monitoring per se, but at least misleading in troubleshooting (was the build node really AWOL?)

[jimklimov]

In a recent event, it seems fhe system actually rebooted (not always the case), started with correct time by HW RTC on the HAT and/or by "recorded timestamp", later went back 20 mins by fake-hwtime, then jumped forward by 20 mins once it saw NTP - and that jump might well be what confused upsmon. Anyhow, it should have reacted like this to a jump, avoiding stale UPS with possibly last known OB state, and so a needless FSD. This part was expected fir this ssituation.

I still wonder what happened in other cases though.

[jimklimov]

Reports on the mailing list confirm the problem on FreeBSD and NetBSD, so the trouble is more likely in our code (e.g. too impatient a delay, or possibly misleading message attached to otherwise correct criteria of skipping too many polling cycles?) than in interactions with systemd inhibitor feature specifically.