[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 11:50:16 BST 2025


Follow-up: my memory failed me, so this point is moot:

>  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?

There are no `wall()` or `notify()` calls from `runparent()` context of
`upsmon.c`, so nothing to discuss about security here. If end-users'
`SHUTDOWNCMD` scripts issue anything - that is up to them.

Jim


On Mon, Sep 29, 2025 at 2:01 AM Jim Klimov <jimklimov+nut at gmail.com> wrote:

> 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/5b9afd04/attachment.htm>


More information about the Nut-upsdev mailing list