Hi,
I noticed an issue with running NUT Client on my proxmox host.
It's not that it's not working, but rather it is not updating the state of the UPS after a calibration. So at some point the NUT Server will run a calibration and if NUT Client get's that status, it won't reset to the regular OL State once the calibration is done. Which means it will shut down the Server if there is any network interruption.
For example I changed a VLAN Tag on my switch (different port, not related to proxmox at all) which results in a very brief (sub 1s) connection loss. The result was this:
Checking the status of my UPS shows
I also didn't take the exact pveversion before and updated the node since - it was on pve 9.2 before.
NUT Server is my Truenas (Baremetal, not a proxmox VM) System, there are 3 other systems connected to the same NUT Server: a pfSense 2.7 box, a Ubuntu 24.04 Server and a QNAP NAS.
None of the other hosts show the same behaviour.
I found this issue which seems to be exactly my problem.
In short: there was a regression in nut 2.8.1 that causes this exact behaviour. It got resolved in nut 2.8.2, but that apparently isn't available on debian trixie yet. I haven't found much about a backport so assuming there hasn't been one.
There is an open bug report for debian without update since 2023.
So it looks like this is a bug within the packaged NUT Version for debian, but I wonder if you are aware of any workaround in the meantime? Or do you see an option to poke the open issue on debian to get this resolved?
Thanks!
I noticed an issue with running NUT Client on my proxmox host.
It's not that it's not working, but rather it is not updating the state of the UPS after a calibration. So at some point the NUT Server will run a calibration and if NUT Client get's that status, it won't reset to the regular OL State once the calibration is done. Which means it will shut down the Server if there is any network interruption.
For example I changed a VLAN Tag on my switch (different port, not related to proxmox at all) which results in a very brief (sub 1s) connection loss. The result was this:
Code:
Sep 10 22:21:10 pve07 nut-monitor[2077]: Poll UPS [redacted] failed - Server disconnected
Sep 10 22:21:10 pve07 nut-monitor[2077]: Communications with UPS redacted lost
Sep 10 22:21:10 pve07 nut-monitor[2077]: UPS [redacted] was last known to be calibrating and currently is not communicating, assuming dead
Sep 10 22:21:10 pve07 nut-monitor[2077]: Executing automatic power-fail shutdown
Sep 10 22:21:10 pve07 nut-monitor[2077]: Auto logout and shutdown proceeding
Sep 10 22:21:10 pve07 nut-monitor[3054671]: Network UPS Tools upsmon 2.8.1
Sep 10 22:21:10 pve07 nut-monitor[3054677]: Network UPS Tools upsmon 2.8.1Checking the status of my UPS shows
ups.status: OL so the UPS itself knows the correct state. I did not check the client before applying the changes on my switch because I didn't expect that to shut down the proxmox node immediately. I also didn't take the exact pveversion before and updated the node since - it was on pve 9.2 before.
NUT Server is my Truenas (Baremetal, not a proxmox VM) System, there are 3 other systems connected to the same NUT Server: a pfSense 2.7 box, a Ubuntu 24.04 Server and a QNAP NAS.
None of the other hosts show the same behaviour.
I found this issue which seems to be exactly my problem.
In short: there was a regression in nut 2.8.1 that causes this exact behaviour. It got resolved in nut 2.8.2, but that apparently isn't available on debian trixie yet. I haven't found much about a backport so assuming there hasn't been one.
There is an open bug report for debian without update since 2023.
So it looks like this is a bug within the packaged NUT Version for debian, but I wonder if you are aware of any workaround in the meantime? Or do you see an option to poke the open issue on debian to get this resolved?
Thanks!