Nut upsdev - Aug 2023 - Setting up charge/voltage based shutdowns

Hello all again,

  While looking at https://github.com/networkupstools/nut/issues/2014 I
understood that I am
not sure if currently NUT has a standard way of triggering a shutdown based
on remaining charge
or runtime, if a device/driver lacks a `battery.charge.low` setting but has
readings for the values
themselves.

  Such an ability rings a bell to me, but maybe it is specific to some
drivers and is not
something ubiquitous - as being in the driver (and/or upsmon/upssched?)
core codebase?

  So there are a few questions stemming from this:
* Can a user currently (on NUT 2.8.0) set up battery percentage based
shutdowns
  when the "low" variable is missing in the driver/device?
(Suggestions in
the ticket
  linked above are welcome)
* Does it make sense to add something like this (if missing) to be
consistent on
  un-capable devices? Or is it already there but too buried in code or docs?
* Would anyone step up to make this setup easy for newcomers (even if it
means "just"
  finding a chapter in the docs/FAQ and making it better exposed, perhaps
in the Wiki),
  or more so if design and coding are due? ;)

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230806/1265b945/attachment.htm>

I think it can be useful in a scenario like:

- Large UPS, that powers 2 hosts: one is VMServer with just a small boot driver
and the second is a NAS with all the disks for the first server.
- UPS is connected by USB to another host (such as a small Raspberry PI), acting
as the NUT primary.
- Both machines served by UPS are NUT secondaries.
- The NAS box can only shutdown one the VMware is fully stopped to avoid
corruption at several levels.

If the secondaries can define their one parameters for initiating the shutdown,
one can decide something like:

- VMware will shutdown at 20% battery left OR 15min of runtime left
- NAS will shutdown at 10% ou 8min left

Another approach is to attempt to define a way to sync secondaries? but that?s
much more complex.

Arnaldo.  
> On Aug 6, 2023, at 12:39 PM, Jim Klimov via Nut-upsuser <nut-upsuser at
alioth-lists.debian.net> wrote:
> 
> Hello all again,
> 
>   While looking at https://github.com/networkupstools/nut/issues/2014 I
understood that I am
> not sure if currently NUT has a standard way of triggering a shutdown based
on remaining charge
> or runtime, if a device/driver lacks a `battery.charge.low` setting but has
readings for the values
> themselves.
> 
>   Such an ability rings a bell to me, but maybe it is specific to some
drivers and is not
> something ubiquitous - as being in the driver (and/or upsmon/upssched?)
core codebase?
> 
>   So there are a few questions stemming from this:
> * Can a user currently (on NUT 2.8.0) set up battery percentage based
shutdowns
>   when the "low" variable is missing in the driver/device?
(Suggestions in the ticket
>   linked above are welcome)
> * Does it make sense to add something like this (if missing) to be
consistent on
>   un-capable devices? Or is it already there but too buried in code or
docs?
> * Would anyone step up to make this setup easy for newcomers (even if it
means "just"
>   finding a chapter in the docs/FAQ and making it better exposed, perhaps
in the Wiki),
>   or more so if design and coding are due? ;)
> 
> Jim
> 
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230806/e7e8ebb7/attachment.htm>

Yeah, I have no lack of imagination about scenarios where that can be
useful - just was surprised to see no apparent "here's how you do
it" sort
of man page or something,

Although technically the shutdown scenario like yours, where a NAS server
only is told to go down - or actually does so (which is substantially
different and can be implemented elsewhere) - after its consumers go down,
can be implemented outside of NUT.

For your example, one can have the NAS's `SHUTDOWNCMD` script wait until
`upsc` reports some critical remaining time/charge or until all known
protocol clients (NFS, CIFS, iSCSI, ...) have disconnected - e.g. check
whether `netstat -an | grep ESTABLISHED | grep PORTNUMS` port count went to
zero (assuming TCP connections). In this case, some same event trigger on
the NUT `primary` server (like "on battery for over 1 minute per
upssched")
would tell all clients to shut down, and the NAS client would by such
script wait until the VM server goes down. Although in this 1:1 case it
would be beneficial for NAS to be the primary server (otherwise the other
primary can eventually time out and take action to go down itself and
command the UPS to power-off). Whatever the programmatic case, in the end
this is limited by how long the UPS holds up :)

Jim


On Sun, Aug 6, 2023 at 6:05?PM Arnaldo Viegas de Lima <
arnaldo at viegasdelima.com> wrote:
> I think it can be useful in a scenario like:
>
> - Large UPS, that powers 2 hosts: one is VMServer with just a small boot
> driver and the second is a NAS with all the disks for the first server.
> - UPS is connected by USB to another host (such as a small Raspberry PI),
> acting as the NUT primary.
> - Both machines served by UPS are NUT secondaries.
> - The NAS box can only shutdown one the VMware is fully stopped to avoid
> corruption at several levels.
>
> If the secondaries can define their one parameters for initiating the
> shutdown, one can decide something like:
>
> - VMware will shutdown at 20% battery left OR 15min of runtime left
> - NAS will shutdown at 10% ou 8min left
>
> Another approach is to attempt to define a way to sync secondaries? but
> that?s much more complex.
>
> Arnaldo.
>
> On Aug 6, 2023, at 12:39 PM, Jim Klimov via Nut-upsuser <
> nut-upsuser at alioth-lists.debian.net> wrote:
>
> Hello all again,
>
>   While looking at https://github.com/networkupstools/nut/issues/2014 I
> understood that I am
> not sure if currently NUT has a standard way of triggering a shutdown
> based on remaining charge
> or runtime, if a device/driver lacks a `battery.charge.low` setting but
> has readings for the values
> themselves.
>
>   Such an ability rings a bell to me, but maybe it is specific to some
> drivers and is not
> something ubiquitous - as being in the driver (and/or upsmon/upssched?)
> core codebase?
>
>   So there are a few questions stemming from this:
> * Can a user currently (on NUT 2.8.0) set up battery percentage based
> shutdowns
>   when the "low" variable is missing in the driver/device?
(Suggestions in
> the ticket
>   linked above are welcome)
> * Does it make sense to add something like this (if missing) to be
> consistent on
>   un-capable devices? Or is it already there but too buried in code or
> docs?
> * Would anyone step up to make this setup easy for newcomers (even if it
> means "just"
>   finding a chapter in the docs/FAQ and making it better exposed, perhaps
> in the Wiki),
>   or more so if design and coding are due? ;)
>
> Jim
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230806/c3fc31ea/attachment-0001.htm>

On Sun, 6 Aug 2023, Jim Klimov via Nut-upsdev wrote:
> ? While looking at https://github.com/networkupstools/nut/issues/2014 I
understood that I am
> not sure if currently NUT has a standard way of triggering a shutdown based
on remaining charge
> or runtime, if a device/driver lacks a `battery.charge.low` setting but has
readings for the values
> themselves.
My personal choice is to shut down after a some time, in my case 2 minutes.  How
much of the battery charge this consumes is a matter for the initial 
configuration of the setup.  The "shutting down now" message says how
much
charge is left.

However I have the impression that this strategy is not popular.

In the case of repeated wall power failures, the shutdown when battery charge 
drops to x% doesn't work.   Better would be shutdown when battery drops BY
y%.

Roger

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
>   While looking at https://github.com/networkupstools/nut/issues/2014
> I understood that I am not sure if currently NUT has a standard way of
> triggering a shutdown based on remaining charge or runtime, if a
> device/driver lacks a `battery.charge.low` setting but has readings
> for the values themselves.
I am unaware of such a facility, but I think we should have it, and it
should be integrated enough that people don't need to use upssched.

My sketch:

  Accept that "LB" is baked into nut pretty hard.  Redefine LB as
  "driver says that it's time to shutdown", which is not
necessarily the
  same as "hardware says battery is almost empty".

  Allow some generic config, to say:

    should LB be triggered on hardware LB (default yes)
    trigger LB if battery% < X (default not)
    trigger LB if battery voltage < Y (default not)
    trigger LB if battery runtime < Z (default not)
    trigger LB if time on battery > W (default not)
  
  except that a driver can set defaults to trigger LB differently if it
  doesn't have a hardware LB indication.   Those defaults should be the
  traditional "maximize runtime".

  Admins that don't like this (and I don't like it either) should be
  able to easily configure a variable in upsd.conf to make things
  shutdown faster, for those that want more margin, or for those who
  think the point is to protect the equipment, not provide availability
  (the "if power is not back in 2 minutes, it's going to be longer than
  my runtime, so just shutdown" crowd -- and I'm very sympathetic to
  that use case).

  Or perhaps this involves renaming the flag passed around to be
  something other than LB, but it's basically "battery status is such
  that the sysadmin has said that in this condition, it's time to shut
  down".  But it does involve decoupling a hardware battery-is-critical
  indication from the nut-it's-time-to-shutdown LB flag.