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 <[email protected]> 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 > >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
