<div dir="ltr"><div>As a follow-up, that R&D led to several other issues and PRs, now mostly merged and summarized in <a href="https://github.com/networkupstools/nut/issues/1781#issuecomment-1519824607">https://github.com/networkupstools/nut/issues/1781#issuecomment-1519824607</a> (with a few points still awaiting completion).<br><br>They added new features to NUT master branch, including:</div><div>* drivers/upsdrvquery.{c,h}: mini-client for socket protocol, so drivers (and upsdrvctl) can talk to the already-running driver instance, if any, other than by sending signals and making guesses if they were handled; this mini-client is usable for SET and INSTCMD with TRACKING and timeouts on POSIX and WIN32 builds</div><div>* This mini-client is used to enable `programname -c reload-or-error` commands on both platforms, allowing callers to either reload driver configurations "on the fly" where supported (e.g.. `debug_min` setting; more can be revised by specific driver maintainers) or to return an exit-code stating that a driver restart is required to apply the configuration change</div>* The exit-code is integrated with `nut-driver-enumerator` service (systemd/SMF) to decide whether a detected change in an `ups.conf` section requires re-definition (and restart) of a service instance for the `nut-driver` (which was the knee-jerk reaction to any change until now, since we only track checksums of config sections and do not know what exactly changed), or if a live reload suffices - improving driver uptime during troubleshooting investigations<div>* On both platforms, clients to the socket protocol (e.g. `server/sockdebug(.exe)`) can newly `SET driver.debug NUM` to change verbosity on the fly</div><div>
* On both platforms, clients to the socket protocol 

can `SET driver.flag.allow_killpower 1` (failsafe that can be pre-configured via `ups.conf`) and `INSTCMD driver.killpower` to request that the running driver does the "force shutdown" equivalent of earlier `drivername -k`. In fact, handling of the latter was changed to try using the running driver (if any) first, and try the old approach of possibly killing off that driver process and starting a new device connection to request its poweroff only if the INSTCMD did not report successful handling (meaning that its `upsdrv_shutdown()` method returned - some are no-ops, a few are infinite loops waiting for power state). As a consequence, this allows OS integrations to revise just how the shutdown is handled - e.g. if the nut-driver services should be stopped at all before the endgame (`upsmon` and `upsd` may well be stopped, socket protocol does not depend on them).<br></div><div>* On POSIX platforms currently (WIN32 equivalent to complete later) some more commands and notably signals are available for configuration reloading (including `reload-or-restart` for driver-wrapping service instances) and troubleshooting.<br></div><div>
<div>* Note that `upsdrvctl` is limited to devices persistently defined in 
`ups.conf`, but drivers called directly can signal their instances 
spawned with `-s TempUPSname` experiments.</div><div><br></div><div>That was a fun if bumpy ride :)</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov<br></div><div></div>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 19, 2023 at 5:18 PM 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="ltr"><div>Cheers,</div><div><br></div><div>  With <a href="https://github.com/networkupstools/nut/pull/1906" target="_blank">https://github.com/networkupstools/nut/pull/1906</a> and <a href="https://github.com/networkupstools/nut/pull/1912" target="_blank">https://github.com/networkupstools/nut/pull/1912</a> (and probably some more later), I've been enhancing NUT driver framework with support for live reload of configuration, primarily to acknowledge changes to debug_min setting in ups.conf - but made in a generic fashion that specific drivers may take advantage of for their `addvar`'ed options handling (as a separate effort from users/maintainers of those drivers).</div><div><br></div><div>  Live testing and other forms of review would be welcome :)<br></div><div><br></div><div>Jim</div><div><br></div></div>
</blockquote></div>