<div dir="ltr"><div>Follow-up: my memory failed me, so this point is moot:<br><br>>  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?<br><br></div><div>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.</div><div><br></div><div>Jim</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Sep 29, 2025 at 2:01 AM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hello all,<div dir="auto"><br></div><div dir="auto">  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 <a href="https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests" target="_blank">https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests</a> -- although at least drivers can then be tested from the build workspace without installing them into the system:</div><div dir="auto"><br></div><div dir="auto">* <a href="https://github.com/networkupstools/nut/pull/3083" target="_blank">https://github.com/networkupstools/nut/pull/3083</a> - 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</div><div dir="auto">...and <a href="https://github.com/networkupstools/nut/pull/3095" target="_blank">https://github.com/networkupstools/nut/pull/3095</a></div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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...)?</div><div dir="auto"><br></div><div dir="auto">--------</div><div dir="auto"><br></div><div dir="auto">Beside that, a couple of PRs regarding upsmon and upssched would also benefit from some attention:</div><div dir="auto"><br></div><div dir="auto">* <a href="https://github.com/networkupstools/nut/pull/3097" target="_blank">https://github.com/networkupstools/nut/pull/3097</a> - upssched: Pass NOTIFYTYPE and UPSNAME into timer executions again, now with relevant values</div><div dir="auto"><br></div><div dir="auto">As it says on the tin :)</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">* <a href="https://github.com/networkupstools/nut/pull/3086" target="_blank">https://github.com/networkupstools/nut/pull/3086</a> - upsmon: fix SHUTDOWNEXIT behavior; tag sub-processes in log records</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">At the time of this writing, PR 3086 is not yet merged, so this has to be built from its source branch.</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Thanks in advance,</div><div dir="auto">Jim Klimov</div><div dir="auto"><br></div></div>
</blockquote></div>