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

Hi Jim,
I was thinking about setting different values for each device , so the first
system has higher values and
shutdowns?earlier:override.battery.charge.lowoverride.battery.runtime.low
Won?t it work ?
Best Regards,Strahil Nikolov?
On Sunday, August 6, 2023, 7:41 PM, Jim Klimov via Nut-upsdev <nut-upsdev at
alioth-lists.debian.net> wrote:

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 amnot sure if currently NUT has a standard way of triggering a
shutdown based on remaining chargeor runtime, if a device/driver lacks a
`battery.charge.low` setting but has readings for the valuesthemselves.
? Such an ability rings a bell to me, but maybe it is specific to some drivers
and is notsomething 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



_______________________________________________
Nut-upsdev mailing list
Nut-upsdev at alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev



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

>From my understanding, alone with other NUT behaviors it would not.
Even if NUT drivers already do (or are changed to) react to the actual
charge/runtime going below this setting to fabricate an LB status, this as
a driver setting/override would have immediate effect on all clients like
`upsmon` watching the device status on their shared data server. This
simultaneously requested shutdown *might* then be handled differently by
shutdown procedures on different clients (e.g. a NAS somehow waiting until
its clients disconnect), but such solutions are not part of NUT directly at
the moment.

If such a feature is indeed missing currently, engineering it would be a
useful addition as it is something people sort-of-expect NUT to be capable
of.

But for different clients to get the shutdown signal at different times
might need something different in e.g. `upsmon`.

One idea that comes to mind though would be to use dummy-ups (or clone*)
drivers as relays, specifically to inject custom overrides (if/when that
mechanism works to generate LB) over "real device" data. So your
server
could have a "realups" section as well as some dummies proxying its
other
info and overridden to have LBs at say 90%, 50% and 30% marks. And
different clients would monitor different such constructs.

Jim



On Sun, Aug 6, 2023 at 7:59?PM Strahil Nikolov <hunter86_bg at yahoo.com>
wrote:
> Hi Jim,
>
> I was thinking about setting different values for each device , so the
> first system has higher values and shutdowns earlier:
>
> override.battery.charge.low
>
> override.battery.runtime.low
>
>
> Won?t it work ?
>
> Best Regards,
> Strahil Nikolov
>
> On Sunday, August 6, 2023, 7:41 PM, Jim Klimov via Nut-upsdev <
> nut-upsdev at alioth-lists.debian.net> wrote:
>
> 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
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230806/a22de990/attachment-0001.htm>