[Nut-upsuser] Nut-upsuser Digest, Vol 231, Issue 2

[Jim Klimov]

By side effect, lack of "killpower" touch file works to not-tell the OS
shutdown integration on OMV to turn off the UPS. A more proper way about
this is generally to change

MONITOR back-ups 1 monmaster 4L[p9<0Vi|Z>xKgK master

(see my earlier message or docs about primary/master vs. secondary/slave
clients), to

MONITOR back-ups 1 monmaster 4L[p9<0Vi|Z>xKgK slave

and it should not even try to turn off the UPS either (nor wait for any
other "upsmon" clients before shutting down itself).

> maybe because the UPS sees 2 systems and only one system is down maybe
that is why the UPS was going panic mode because it can't shut down the
other system that it has to power cycle to bring back operations to normal

UPS itself normally has no idea what it feeds (enterprise ones aside), it
is told to turn off and it does remove power from the load
(computers/routers/etc.) It is not "shutting down" anyone, either: NUT is -
on systems that have an `upsmon` client and which subscribe to `MONITOR` a
NUT data server like that running on your OMV.

So there's no "panic mode" about it - OMV ran NUT `upsmon` in master mode,
and it created a `killpower` file when issuing FSD alert, and the OS
integration on OMV saw that file and commanded the UPS to power off because
this is the master system and everybody listens to it, and it sinks last -
or so is assumed by the design.

If the wall power is back, UPS turns on again if set up and wired to do so
(maybe after having the battery "sufficiently" charged).

Note that in your desired setup, OMV goes down, UPS and gaming/router/...
live on, and either they die suddenly when the battery is finished, or wall
power returns and UPS keeps humming and OMV server stays off until you
press its power button (or research if wake-on-LAN can be sent from e.g.
router's SSH shell if you're not home). This may be or not be what you want
to achieve.

> also my Gaming PC is using windows maybe thats why FSD is not taking
effect on it

FSD is a NUT concept. While there is a build of NUT for Windows, so your
gaming PC could run an `upsmon` client for its own shutdowns (listening to
OMV for UPS state info), it seems at the moment it does not. Let's not
complicate things for now :)

Hope this helps,
Jim Klimov


On Sun, Sep 8, 2024, 02:28 Mega DooOooM <princemodey at hotmail.com> wrote:

> No only Server PC is connected to my UPS with USB and the only PC with NUT
>
> as i told Mr.Roger
> POWERDOWNFLAG /etc/killpower
>
> this line might be the culprit it kills my UPS after it shuts down my
> SERVER after 300 seconds
> in the documentation he gave me it said something like forcing the UPS to
> shut down because it is Primary/Critical or something like it
> i will try with that line POWERDOWNFLAG /etc/killpower removed and see
> what happens
>
>
> also my Gaming PC is using windows maybe thats why FSD is not taking
> effect on it
>
> so far what i tried after removing that line
>
> TEST 1
>
> SERVER PC / ROUTER / SWITCH
> power goes down UPS goes to BATTERY mode --- shuts down my SERVER --- and
> when the power is back the UPS switches back to AC mode without any power
> cycle to my UPS
>
> TEST 2
>
> GAMING PC / ROUTER / SWITCH
> power goes down UPS goes to BATTERY mode and when the power is back the
> UPS switches back to AC mode without any power cycle to my UPS
>
> the last test will be
>
> SERVER PC / GAMING PC / ROUTER / SWITCH
> and see if your theory is correct or that line was the culprit
> i also thought that maybe because the UPS sees 2 systems and only one
> system is down maybe that is why the UPS was going panic mode because it
> can't shut down the other system that it has to power cycle to bring back
> operations to normal or KILLING my other system in order to abide by the
> first command from NUT we will see though that is why i'm testing right now
>
>
> and sorry to ask this of you but how can i make OMV see my UPS as
> secondary i read something about that primary UPS from the Documentation
> but because i'm not an expert i don't know what conf file to edit or what
> line to add/edit to make this happen a little help from you would be great
>
> Thanks in advance and really sorry to disturb your day gentlemen.
>
>
>
> ------------------------------
> *From:* Jim Klimov <jimklimov+nut at gmail.com>
> *Sent:* Sunday, September 8, 2024 12:27 AM
> *To:* Mega DooOooM <princemodey at hotmail.com>
> *Cc:* nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org>
> *Subject:* Re: [Nut-upsuser] Nut-upsuser Digest, Vol 231, Issue 2
>
> Cheers, jumping into the discussion late from some travels, sorry.
>
> In the original post, is the "Server PC" the OMV with NUT? Are any of your
> other machines running NUT (e.g. the `upsmon` client for shutdowns)?
>
> What I guess may be happening is:
>
> * OMV has the physical connection needed to monitor and command the UPS,
> and its `upsmon` has `MONITOR` for it as `primary` (ex-`master`);
> * by definition, such a "primary" instance in case of a power outage (and
> "critical state" of the UPS battery, definitions vary) is responsible for
> yelling "FSD" (Forced ShutDown) to all other "secondary" clients connected
> to tge same `upsd` data server (maybe none in your case), waiting for them
> all (if any) to disconnect - presumably meaning they are going down, and
> shuts down itself.
> * With the "killpower" file in place (created as part of "primary" FSD
> handling), and some OS shutdown integration, it would also tell all
> connected UPSes to power off (or power-cycle if power came back, aka "power
> race condition", to avoid your systems staying down indefinitely), if the
> UPS and its NUT driver agree how to support such behavior.
>
> This seems aligned with what you see in practice.
>
> One quick fix can be to change the OMV `MONITOR` mode to `secondary`
> (ex-`slave`) so only it shuts down when power goes "bad".
>
> Nuanced criteria for the latter, like time spent on battery, can be set in
> `upssched` (as asked about by Roger). Default "bad"ness is defined by UPS
> itself claiming a low battery state, maybe also by remaining percentage
> (depends on driver and device).
>
> Hope this helps,
> Jim Klimov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240908/f4706a87/attachment-0001.htm>