FWIW, added this to Wiki: https://github.com/networkupstools/nut/wiki/Monitoring%E2%80%90only-NUT-clients
On Thu, May 2, 2024 at 11:57 AM Jim Klimov <jimklimov+...@gmail.com> wrote: > Hello, and welcome to the NUT community! :) > > 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. > > 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. > > 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). > > 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. > > Hope this helps, > Jim Klimov > > > On Thu, May 2, 2024 at 9:22 AM Alexander Hofmann via Nut-upsuser < > nut-upsuser@alioth-lists.debian.net> wrote: > >> Dear all, >> >> I might have a somewhat strange question (which might arise from my >> [rather unusual?] use case, see below): Is it possible to put the >> "blazer_usb" driver (or NUT in general) to something like a "read only" >> or "monitor only" mode in respect to the communication with the >> hardware? The idea would be to not allow NUT to switch off the power at >> the UPS at all. >> >> Currently, I disabled the "KILLPOWER" switch, so that "upsdrvctl >> shutdown" is not called when the monitoring system is shut down (that's >> what I read in all the guides I could find online, and the only thing >> related in the manpages AFAIK). But I'm not sure what else to disable or >> change. So I though, if there's the ability to disable "control" to the >> UPS entirely at driver level, this would be the most "permanent" >> solution to make sure no "accident" occurs? >> >> >> If you have another Idea, here's the "real" problem: >> >> I'm monitoring a UPS (FSP "Clipper", working with driver blazer_usb) >> that's controlling power to a inert-gas glovebox-system in a laboratory, >> with some additional "support" hardware. The goal is to record power >> usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The >> system actually has no means to be "safely shutdown" in an automated >> way, so most of the usual "protocols" to follow for servers or storage >> or... do not apply to the system itself. I can of course control other >> devices or shutdown stuff that's not mandatory to reduce power usage. >> Thus: I might issue shutdown commands to PCs, power strips etc. powering >> measurement equipment, or the monitoring system, but will keep the "main >> thing" running as long as the UPS hardware can handle it (at that time, >> all other "intelligent" devices are already off, including NUT itself, >> at least that's the plan). Such an event occurs maybe once a year, if at >> all... >> >> So far, I think disabling UPS shutdown at system shutdown is the only >> thing I really need, but as the system is rather crucial to our >> workflow, I wanted to make sure. The more changes I have to make to the >> "default" configuration, the more to check at each update... >> >> Thank you for your patience in reading my story :-) >> >> >> Best regards, >> >> Alex >> >> >> >> _______________________________________________ >> Nut-upsuser mailing list >> Nut-upsuser@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >> >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser