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?
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>

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
>  >> 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.
That's all fair, except the bit about storage wear, because creating one
file every year or so is hard to get excited about.  But /etc being read
only is significant for embedded, and making sure it's gone on reboot is
a big deal.

This is leading me to think that the entire scheme has gotten too
complicated, and that there should basically be two configure switches,
for

  /var/run-ish dir for use by nut as root
  /var/run-ish dir for use by nut as nutuser

which would have

  pidfiles
  sockets
  killpowe flag

and I'm not sure there is anything else.  Whether the /var/run-ish dir
is tmpfs (and hence clear on boot) or cleared by the system on boot is a
system issue.

It's not really harmful to have n configs for the separate things, but I
don't see an argument for having more places.

I had read the "Also the upsmon POWERDOWNFLAG fits into this question"
in your response as you meant the flag belonged in the persistent state
directory.