<div dir="ltr"><div dir="ltr"><div>Hello, and welcome to the NUT community! :)</div><div><br></div><div>  On one hand, it would generally help to read up the documentation about NUT architecture, seeing as it is a crucial part of your systems' uptime and data integrity.</div><div><br></div><div>  On another hand, for this particular use-case: it is quite possible to set up monitoring-only systems which only inform you if some *other* NUT data server has had interesting situations, or mixed-monitoring systems for that matter.</div><div><br></div><div>  The software part of NUT responsible for actually shutting down a computer is typically the `upsmon` client, whose `SHUTDOWNCMD` setting (in `upsmon.conf`) defines how to go about the routine. NUT drivers do interact with devices (and can send power-off commands to supported UPSes in case of `killpower` flag being processed), but they do not make the decision to do so - the `upsmon` client running on that box does, based on it being the primary (ex-master) system for the UPS meaning it has the physical media to talk to the device (serial/USB/networked/...). An `upsmon` client running in "primary/master" mode on the system that can actually talk to the UPS would have a `MONITOR` line with specification of how many PSUs of this server that UPS feeds (1 or more) and a `MINSUPPLIES` line to specify how many PSUs (1+) should be fed to consider the server capable of running indefinitely as far as having power is the question. On redundant servers you can have something like "1 of 2 is okay", or "1..3 out of 4" depending on the blade chassis population, etc. When the situation gets critical, a "primary" `upsmon` client would set the local `KILLPOWER` flag which would cause the OS late-shutdown scripts (where supported) to run a driver instance talk to the UPS again and tell it to power off and recycle when safe to do so (and thus avoid the "power race condition" where the wall power comes back while half of your rack is already down, so it sits for days waiting for someone to power all servers back on).<br></div><div><br></div><div>  As far as monitoring-only clients are concerned, you can set the argument to the MONITOR line un `upsmon.conf`, that the tracked (and often "secondary") UPS feeds zero (0) power sources of this particular monitoring box, which makes sense if it sits in a different building for example. Orthogonally to that, you can also specify `MINSUPPLIES 0` to a purely monitoring system, impacting the trigger for its own shutdown (as long as that many PSUs are fed, all is okay). In a mixed system, having its own UPS(es) and monitoring some remote NUT data servers, you would have a mix of "local" MONITOR lines with a non-zero count of PSUs fed (summing up to your MINSUPPLIES for a healthy uptime) and other MONITOR lines with the zero amount of fed PSUs.</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 2, 2024 at 9:22 AM Alexander Hofmann via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear all,<br>
<br>
I might have a somewhat strange question (which might arise from my <br>
[rather unusual?] use case, see below): Is it possible to put the <br>
"blazer_usb" driver (or NUT in general) to something like a "read only" <br>
or "monitor only" mode in respect to the communication with the <br>
hardware? The idea would be to not allow NUT to switch off the power at <br>
the UPS at all.<br>
<br>
Currently, I disabled the "KILLPOWER" switch, so that "upsdrvctl <br>
shutdown" is not called when the monitoring system is shut down (that's <br>
what I read in all the guides I could find online, and the only thing <br>
related in the manpages AFAIK). But I'm not sure what else to disable or <br>
change. So I though, if there's the ability to disable "control" to the <br>
UPS entirely at driver level, this would be the most "permanent" <br>
solution to make sure no "accident" occurs?<br>
<br>
<br>
If you have another Idea, here's the "real" problem:<br>
<br>
I'm monitoring a UPS (FSP "Clipper", working with driver blazer_usb) <br>
that's controlling power to a inert-gas glovebox-system in a laboratory, <br>
with some additional "support" hardware. The goal is to record power <br>
usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The <br>
system actually has no means to be "safely shutdown" in an automated <br>
way, so most of the usual "protocols" to follow for servers or storage <br>
or... do not apply to the system itself. I can of course control other <br>
devices or shutdown stuff that's not mandatory to reduce power usage. <br>
Thus: I might issue shutdown commands to PCs, power strips etc. powering <br>
measurement equipment, or the monitoring system, but will keep the "main <br>
thing" running as long as the UPS hardware can handle it (at that time, <br>
all other "intelligent" devices are already off, including NUT itself, <br>
at least that's the plan). Such an event occurs maybe once a year, if at <br>
all...<br>
<br>
So far, I think disabling UPS shutdown at system shutdown is the only <br>
thing I really need, but as the system is rather crucial to our <br>
workflow, I wanted to make sure. The more changes I have to make to the <br>
"default" configuration, the more to check at each update...<br>
<br>
Thank you for your patience in reading my story :-)<br>
<br>
<br>
Best regards,<br>
<br>
Alex<br>
<br>
<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div></div>