<div dir="auto">Hi, and nice to hear it (mostly) suits you :)<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Hope this helps,</div><div dir="auto">Jim Klimov</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 25, 2022, 13:22 Shaun Currier 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>First of all, I'd like to compliment NUT on having great documentation and hardware support!<br></div><div><br></div><div>My issue:<br></div><div>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.<br></div><div><br></div><div>My configuration is mostly default settings, but HOSTSYNC is set to 120.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Thanks for any help you can provide!</div></div>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>