Hello,
Package: nut-client
Version: 2.8.1-5
Confirming this on trixie, and asking whether it can go into stable.
Fixed upstream in 2.8.2 -- NEWS.adoc, "what's new since 2.8.1":
* `upsmon` recognition of `CAL` state could linger after the calibration
activity was completed by the hardware, which led to mis-processing of
shutdown triggers. Also, notification was added to report "finished
calibration". [issue #2168, PR #2169]
https://github.com/networkupstools/nut/pull/2169
(Same root cause as #1056190, fixed in 2.8.3-1, presenting the opposite way.)
Evidence, two secondaries on the same UPS, 2026-08-18. Weekly self-test at
06:40, 13 seconds of OB CAL. NUT 2.8.5 logged "calibration finished" and
cleared it; 2.8.1-5 never did. 22 minutes later a switch firmware upgrade cut
the path to the NUT server for 71 seconds, and 2.8.1-5 did this:
UPS [...] was last known to be calibrating and currently is not
communicating, assuming dead
Executing automatic power-fail shutdown
It powered off a hypervisor and three guests, unattended. The 2.8.5 host lost
comms across the same 71 seconds and only logged warnings.
Why I think this warrants a stable update: the latch clears only on upsmon
restart, so it re-arms at every weekly self-test and persists for days. Mine
sat armed 04-08 and 11-15 August without incident, purely because nothing
interrupted the network in those windows. On stable, any UPS that self-tests
leaves the machine one interruption away from an unscheduled power-off, and
DEADTIME defaults to 15s -- shorter than a switch reboot.
The criteria look met: fixed in unstable (2.8.4+really-2.1), severity
important, and PR #2169 is small and self-contained, so a +deb13u1 with a
targeted patch rather than a version bump. trixie has no backports build of
nut, so stable users have no route to the fix today.
Happy to test a candidate package; the trigger reproduces weekly.
Appreciate the work.
Kind regards,
Dean
