search

networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
1.73k stars 335 forks source link

Idea for signals without PID files: use NUT protocol #1781

Open jimklimov opened 1 year ago

jimklimov commented 1 year ago

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:

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

jimklimov commented 1 year ago

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

Currently TODO: