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

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>

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>