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 
<[email protected]> 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 
<[email protected]> 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 
<[email protected]> 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
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser



_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev



_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Reply via email to