[Nut-upsdev] [Nut-upsuser] Setting up charge/voltage based shutdowns

[Jim Klimov]

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