>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...@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-ups...@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 < > arna...@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@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@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > > _______________________________________________ > Nut-upsdev mailing list > nut-ups...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev > >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser