Nut upsuser - May 2023 - Synthesize low batt (LB) fron SNMP UPS which does not support this?

On Tue, 16 May 2023, Carsten Aulbert wrote:
> ...  I'm still struggling how to shut down servers fed by two
independent UPS
> systems.
> * Keep nut unpatched but use our own NOTIFYCMD or CMDSCRIPT to pull the
values
> from the server and implement our logic there?
Hello Carsten, That's what I did but for a much simpler setup. I live in an
area
with a lot of lightning, and my shutdown criteria is to be able to shut down 
repeatedly during an electrical storm.  The NOTIFY and CMDSCRIPT and the 
upssched-cmd logic are written up in detail in chapter 7 of 
https://rogerprice.org/NUT/ConfigExamples.A5.pdf .

Chapter 8 contains a detailed description of a hypothetical installation fed by 
multiple UPSs.

Roger

Hi Roger,

On 5/16/23 17:00, Roger Price wrote:
> Hello Carsten, That's what I did but for a much simpler setup. I live
in
> an area with a lot of lightning, and my shutdown criteria is to be able 
> to shut down repeatedly during an electrical storm.? The NOTIFY and 
> CMDSCRIPT and the upssched-cmd logic are written up in detail in chapter 
> 7 of https://rogerprice.org/NUT/ConfigExamples.A5.pdf .
> 
> Chapter 8 contains a detailed description of a hypothetical installation 
> fed by multiple UPSs.
wow, that looks like a LOT of content to digest but I'm not so sure if 
our problems align that well (but then I only briefly skimmed over it).

Luckily for us, our power grid is really stable, I think we only had 4 
or 5 outages lasting more than a fraction of a second over the past ~ 15 
years. Thus, we use our UPSes mainly for providing clean and stable 
power to our computing center with the bonus of have power when the 
mains go down.

We shut down the compute nodes via upssched and a 30s timer. If the 
power cut is shorter than that, they will simply continue running as the 
timer is cancelled by nut. Otherwise they will simply power down and 
stretch our 6-8 minutes battery buffer to much longer.

What I'm more worried about then are the storage servers, networking, 
head nodes and a couple of special nodes which are powered by both UPSes.

We could use upssched also for those nodes, but the pipelining of 
messages makes it a bit hard to have a final "stateful" service
working
around the missing LB flag. This would need to actively query the UPS 
and act after battery.runtime or battery.charge is too low overall. My 
simple approach there did not work (effectively looping in the script) 
as the next message from upssched would simply wait in the pipeline 
while my script was still looping.

We could also use upsmon to call our script instead of upssched which 
then would need to handle being called multiple times and coordinate 
what to do based on the messages being passed.

Both cases would probably need our own running service which would need 
to be fed messages and then act based on their own UPS queries. Probably 
doable, but not that nice.

Idly browsing the client sources, I guess I could try to add our logic 
here[1] and use [2] to gather the battery stats from our UPS and then 
decide if this UPS is considered critical or not. But for this, I would 
need to dust off/excavate my ancient poor C knowledge ;-).

I guess I will give this a try unless someone has a brilliant idea and 
could save my sanity.

Cheers

Carsten

[1] 
https://github.com/networkupstools/nut/blob/e3bdc28476700c7396bdde912e5789ccb7ecb1d7/clients/upsmon.c#L925

[2] 
https://github.com/networkupstools/nut/blob/e3bdc28476700c7396bdde912e5789ccb7ecb1d7/clients/upsclient.h#LL105C1-L107C33

-- 
Dr. Carsten Aulbert, Max Planck Institute for Gravitational Physics,
Callinstra?e 38, 30167 Hannover, Germany, Phone +49 511 762 17185
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4827 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230516/7f693f9a/attachment.bin>