[Nut-upsuser] Proxmox as secondary gets power interrupted during VM shutdown
Jim Klimov
jimklimov+nut at gmail.com
Fri Aug 26 08:56:14 BST 2022
Hi, and nice to hear it (mostly) suits you :)
I think (OTOH so maybe docs/code can prove me wrong) that by issuing FSD
aka ForcedShutDown you yell "abandon ship, battery almost dead!" so it is
time-limited activity in real conditions.
Other than that, the "primary" (ex "master") upsmon normally waits for all
secondaries to log out (or lose connection across too many heartbeats
during a power outage, or maybe in case of FSD take too long anyway) and
starts a chain of events which tells the UPS to power off.
So one thing to look at is, indeed, how Proxmox/Debian packaging sets up
the systemd dependencies between VMs (are they represented by service
units/instances?) and upsmon (nut-client?) - so whether just this
"secondary" (ex "slave") upsmon is not stopping (and logging out from
"primary") just because the OS is shutting down, without regard to other
services. I'd expect upsmon service to only begin stopping when something
like multi-user target has finished stopping, but not sure quickly if
packaging covers that, and/or if VMs are part of that target. Maybe a
"drop-in" file for e.g. nut-client would help you define custom end-of-life
dependencies. Systemd has tons of keywords and nuance interactions to
choose from.
Looking forward to eventual upgrades, note that NUT 2.8.0 (and current git
master) proposed changes to "reference" service layout. Not sure OTOH if
they would handle your case differently, and anyhow distros decide
themselves what they package (our definitions, or their own from older
ages, or a mix).
Regarding auth, not sure quickly what is (acts or feels) wrong. NUT allows
free access to data for monitoring. Logins are for managing (set var, run
cmd, upsmon role) so maybe with a wrong password it falls back to just
keeping track of remote UPS status?.. Maybe starting the program with
higher debug level (e.g. tweaking its service unit temporarily) would
reveal if it logs more about that.
Hope this helps,
Jim Klimov
On Thu, Aug 25, 2022, 13:22 Shaun Currier via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:
> Hello,
>
> First of all, I'd like to compliment NUT on having great documentation and
> hardware support!
>
> My issue:
> I am running Proxmox 6.3-3 with NUT 2.7.4-8 which was installed via apt
> package. It is connected as a secondary through a TrueNAS NUT primary that
> is directly attached to an Eaton 5P750 UPS via USB.
>
> My configuration is mostly default settings, but HOSTSYNC is set to 120.
>
> When I trigger a shutdown event on the primary with `upsmon -c fsd`, I can
> see that Proxmox correctly receives the FSD signal and starts shutting
> down. It takes a long time (~50 seconds) to shut down the guest VM's
> hosted on Proxmox, though, and the process is interrupted by the power
> being "cut." Really, since I'm only manually triggering the FSD and this
> isn't a real power outage, the power cut is merely assumed when the primary
> fully shuts down.
>
> Why is this happening? Shouldn't NUT somehow know that VM's on Proxmox
> are still shutting down, and not disconnect from the primary until it's
> very close to the end of the shutdown process?
>
> Is it possible that the NUT package on Proxmox does not have dependencies
> to other services set correctly, i.e. the NUT service/unit should depend on
> the VM shutdown unit, but it doesn't?
>
> As a side note in case it's related, NUT's user authentication does not
> seem to be enforced in my system. I can change the password to something
> erroneous for the Proxmox's NUT upsmon user, but it can still access the
> NUT primary, which is unexpected. I expect it to get denied access, but
> it's not.
>
> Thanks for any help you can provide!
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220826/c29646ba/attachment.htm>
More information about the Nut-upsuser
mailing list