[Nut-upsdev] Testing of recent NUT updates would be much appreciated (snmp-ups, nutdrv_qx, usbhid-ups; upsmon)

Jim Klimov jimklimov+nut at gmail.com
Mon Sep 29 01:01:04 BST 2025


Hello all,

  Recently some PRs have landed as somewhat theoretical solutions to a
problem, but I currently can't test that all of them behave well - needs
corresponding UPSes to test at least for non-regression (and ideally
delivery of new features). This would involve building NUT from source per
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
-- although at least drivers can then be tested from the build workspace
without installing them into the system:

* https://github.com/networkupstools/nut/pull/3083 - Enhance usbhid-ups to
report use of data points vs. definitions in a subdriver, to not assume
!OL==OB, and to report absent ups.status values
...and https://github.com/networkupstools/nut/pull/3095

Testing here would be around snmp-ups, nutdrv_qx, and usbhid-ups drivers
reporting in debug logs how many of the mappings they have defined were
actually used to set a "dstate" internally. In case of usbhid-ups, it also
says what data it saw in a USB HID report descriptor that was not used by
any mapping (so driver can be improved to support that device better).

This should hopefully help identify poorly supported devices (under 10
mappings used, or falling back to IETF SNMP mapping), and those where
`ups.status` could not be determined, with louder actionable messages
referring to documentation on how to fix the driver or at least contribute
to that.

Code is a bit repetitive there and may get optimized later. So far the main
question is if this is helpful in troubleshooting or too noisy, or even
buggy (leaks, crashes...)?

--------

Beside that, a couple of PRs regarding upsmon and upssched would also
benefit from some attention:

* https://github.com/networkupstools/nut/pull/3097 - upssched: Pass
NOTIFYTYPE and UPSNAME into timer executions again, now with relevant values

As it says on the tin :)

Some releases ago it was found that these envvars were inherited from the
invocation that started the timer and were not necessarily relevant for
other timers. Confusing values were then forgotten with `unsetenv`, which
turned out to not be right either. Now we try better to pass correct values
(maybe comma-separated if several devices or events would
START-TIMER-SHARED with same name).

* https://github.com/networkupstools/nut/pull/3086 - upsmon: fix
SHUTDOWNEXIT behavior; tag sub-processes in log records

This one is best tested installed, to check it drives a shutdown correctly
(especially with regard to secondaries that require a long delay to go
down).

Part of the new feature code is improved debug logging of NUT daemons that
fork around, to see what role that sub-process has (e.g. in case of upsmon,
there is a privileged root parent, an unprivileged loop, and a notification
method).

At the time of this writing, PR 3086 is not yet merged, so this has to be
built from its source branch.

Side note: should notifications from privileged half of upsmon run as root
(e.g. to deliver a visible `wall` to all consoles), or change user account
first? Or add a config option for end-users to choose this behaviour?

Thanks in advance,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250929/a6835a8a/attachment.htm>


More information about the Nut-upsdev mailing list