Nut upsdev - May 2025 - pidpath, altpidpath, statepath considered muddled or confusing

> Also the upsmon POWERDOWNFLAG fits into this question
I'm confused. That flag can't be persistent across reboots, can it?

>> Also the upsmon POWERDOWNFLAG fits into this question
> I'm confused. That flag can't be persistent across reboots, can it?
Well, there is little practical reason, if any, for an `/etc/killpower` (as
it is commonly named) to exist when you boot. It also has a potential for
confusion if not deleted, as we discovered in some recent discussion - e.g.
due to no packaged NUT init scripts running to remove it, and then upon
every shutdown or reboot the late-endgame NUT integration finds it and
tells the UPS to power off because at that point presence of the file means
an FSD is in progress.

So for a few releases now, the documented recommendation is for packagers
to use a tmpfs to place that file (and do so in a root-owned subdirectory).
Side considerations are that this also reduces storage wear where it
matters, and the FS is more likely to be writeable.
Also while the `upsmon` part running as `root` may write into `/etc` if it
is not part of some R/O operating environment image, there is little reason
to mess up its timestamps etc, as some have complained. Common permissions
for `/etc` itself do however ensure the constraints that a rogue
unprivileged program should not be able to create that default file name
and cause a DoS by telling UPSes to turn off.

But these are nuances known when packaging for a particular deployment
strategy, not something that is good to impose out of the box, so the
default is as it was for least-surprise for long-time BYOS rebuilders going
from source.

Hope this helps,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250519/a0f6c5da/attachment-0001.htm>