Idea for signals without PID files: use NUT protocol

[jimklimov]

When upsd or upsmon are started in foreground mode -F, by default they run without a PID file. This precludes use of upsd -c reload and similar command-line activities.

As one idea, NUT protocol could be extended for upsd without a PID file to check if its currently configured port/IP are listened, and query there for a new GETPID command - for the running daemon to respond (PID number on POSIX systems, something else in WIN32), at least if it is not frozen. Then the CLI program instance can send signals to the daemon same as it does now, relying on OS protection with regard to security. Something similar could be done with upsmon instances, having them report PIDs to the data server they are connected to.

Context: this -F option is used in service units to reduce forking since 2.8.0 release. As a consequence, use of modern NUT OS integration precludes classic reload/stop activities via CLI, as users find in documentation or are used to do for years. A workaround is to run units with -FF option to both be foreground and leave a PID file, but this is somewhat not idiomatic for modern services anymore (and currently is only implemented for upsd, while upsmon calls writepid() regardless of fire/back-ground mode).

Alternative idea: NUT programs built with systemd integration can try to query systemctl show -p MainPID nut-monitor.service, and if OS permissions let them do it - use that PID. Possible caveat here is that different populations of NUT builds (e.g. packaged vs. custom-built experiments) might conflict and unexpectedly a system service might be asked to stop; however this should be resolved by using a different unprivileged account to build/test the experiments... In any case, if reliable PID files (e.g. found via built-in paths) are not available, many bets are off.

See also:

• Missing pid-file upsmon.pid and no browsing possible #1721
• upsd.pid/upsmon.pid are important for live config reload (systemd might do without it?) #1299

This is not a high priority issue, just something to think about.

[jimklimov]

Much progress about this in recent PRs (and related issues):

• Expose a driver variable for debug level, settable using upsrw (runtime modifiable) #1285 (which started this line of thinking)
• Support reload operation for drivers (like we have for upsd and upsmon), at least to change debug_min setting #1903
• Driver reload - basic support #1906
• Want a way to dump driver state at run-time #1907
• Support signals (reload, dump...) in upsdrvctl, handle CLI -c CMD for drivers and upsdrvctl #1912
• Explore additional communications with driver by Unix socket (and Windows pipe?) #1914
• Support (optionally?) driver forceshutdown via signal and/or socket protocol (without upsd) #1917
• Extend server-driver socket protocol capabilities #1918
• Extend driver-server socket protocol with verdicts #1920
• Teach upsdrvctl and drivers to talk socket protocol to their other selves #1922
• Extend drivername -k operation to try INSTCMD driver.killpower first, if possible #1923
• Extend nut-driver-enumerator to use INSTCMD driver.reload-or-error #1924
• Complete exit-code passing in upsdrvctl -c driver.reload-or-error command #1927
• Allow upsdrvquery_oneshot() to accept caller's timeout #1929
• Driver main.c: use Unix socket protocol to kill off "Duplicate other instance" #2392
• Implement an INSTCMD driver.exit as alternative to PID files and signals #2393

Currently TODO:

• Complete the driver reload and dump functionality for WIN32 builds #1916
• Extend driver data dump (requested over socket protocol without upsd) with printout by caller #1926
• Add support for TRACKING to (NO)BROADCAST on driver-upsd socket protocol #1928