[Plugin] NUT v2 - Network UPS Tools

[Rysz]

Just now, Alcapone001 said:

 

Same issue

 

 

Did you also try the blazer_usb driver with the legacy backend? You're now using the exact same NUT backend as with the previous plugin (which worked for you) so there's no reason it shouldn't work anymore (at least not because of NUT). Can you also try another USB port? Check your cable connection to the UPS also if nothing is loose. 

[Alcapone001]

Shouldnt the Status be 'Started'

[Rysz]

Warning for users considering to update an existing NUT installation:

 

Be advised that the default backend (including the UPS drivers) is developed further and subject to change.

 

Backend development can never plan for all UPS devices and updating comes with a chance of degraded UPS compatibility.

 

That means if NUT works well for you and you are happy with everything, updating is not going to bring you much benefit.

 

Most of the changes are intended towards simplifying new installations and users having problems with their UPS devices.

 

Please always read the changelog carefully and consider if you really need these changes on your (working) system.

 

For more detailed information about this and the backends, please read this:

 

Edited October 26, 2023 by Rysz

[Alcapone001]

 

[Rysz]

Just now, Alcapone001 said:

 

 

Sorry I don't really know how to help you more here, I think this is a USB connection or USB controller issue more than a NUT issue. It seems the drivers can't see the UPS as USB device.

 

Your UPS series is reported as working with NUT both with blazer_usb and nutdrv_qx drivers, and now you're even using the exact same NUT backend and settings as with the previous plugin (where you said it was working) so it's 100% identical as before as far as NUT is concerned but still not working. That's why I'm guessing it's an issue outside of NUT.

[Alcapone001]

Changing the USB Port Worked. It appears the USB Port i have been using went Kaput at some point..

 

Thank You.

[Rysz]

Just now, Alcapone001 said:

Changing the USB Port Worked. It appears the USB Port i have been using went Kaput at some point..

 

Thank You.

 

Glad you got it working again! 😉

[Rysz]

14 hours ago, Hacky said:

It is currently not possible to use `dummy-ups` driver configuration for the purpose of QNAP (and maybe Synology too?) NAS.

 

Example `ups.conf` configuration which fails to work

maxstartdelay = 150

maxretry = 30

retrydelay = 5

[ups]
driver = "usbhid-ups"
port = "auto"
# your USB UPS configuration follows

[qnapups]
driver = dummy-ups
port = [email protected]
desc = "APC UPS for QNAP"

 

This can be however hotfixed with the following patch for the `/etc/rc.d/rc.nut` file.

--- rc.nut	2023-09-29 19:45:25
+++ rc.nut2	2023-09-29 19:49:39
@@ -15,7 +15,7 @@
 [ -e "$CONFIG" ] && source $CONFIG

 start_driver() {
-    /usr/sbin/upsdrvctl -u root start 2>&1 || exit 1
+    /usr/sbin/upsdrvctl -u root start ups 2>&1 || exit 1
 }

 start_upsd() {
\ No newline at end of file
@@ -247,6 +247,8 @@
             start_upsd
         fi
         start_upsmon
+        sleep 1
+        /usr/sbin/upsdrvctl -u root start qnapups 2>&1 || exit 1
         ;;
     start_upsmon) # starts upsmon only (for a ups client box)
         start_upsmon
\ No newline at end of file

 

(Apply via ssh/terminal with `patch /etc/rc.d/rc.nut < PatchFileIncludingAbovePatch`)

 

With such patch NUT works well and can start both drivers successfully.

 

Maybe someone else will find that helpful.

 

Thanks for sharing this, I'm just curious what the use case for this would be, as opposed to running NUT in regular netserver setting without dummy-ups acting as a repeater and simply naming your UPS "qnapups" in the NUT settings.

 

Edited September 30, 2023 by Rysz

[Alcapone001]

On 9/17/2023 at 5:58 PM, SimonF said:

I am stopping updates for my version of the plugin. Update to the latest version 2023.09.17 and then you can remove my version and install Rysz's from CA and it will retain your configs.

 

There are some nice changes that have been added to the new version.

 

Shouldn't this be added to the OP. This way People can easily pick this up.

 

For instance in my case when setting up NUT for the first time I simply used the instructions in the Original Post.

 

The Plugin was automatically removed later on due to compatibility issues ..

 

Updating the Original Post will easily have helped..

Edited September 30, 2023 by Alcapone001

[SimonF]

4 minutes ago, Alcapone001 said:

 

Shouldn't this be added to the OP. This way People can easily pick this up.

 

For instance in my case when setting up NUT for the first time I simply used the instructions in the Original Post.

 

The Plugin was automatically removed later on due to compatibility issues ..

 

Updating the Original Post will easily have helped..

This is not my thread, I only made it 6.12 compatible. Will see if we can change the OP or may be we should start a new one referring back to this one.

[Alcapone001]

5 minutes ago, SimonF said:

This is not my thread, I only made it 6.12 compatible. Will see if we can change the OP or may be we should start a new one referring back to this one.

 

Okay No Problem.

 

Simply a suggestion based on my challenges.

 

All in all am grateful for those who have taken their time to make this work...

 

As an aside any reason why Unraid mainly supports APC UPS only. Sponsorship? 

[SimonF]

23 minutes ago, Alcapone001 said:

 

Okay No Problem.

 

Simply a suggestion based on my challenges.

 

All in all am grateful for those who have taken their time to make this work...

 

As an aside any reason why Unraid mainly supports APC UPS only. Sponsorship? 

Not that I know off. Suspect at time of integration they where the most common

 

But if it is integrated it could only be refresh at a version change. plugins allow at faster pace of development to the community.

[Kilrah]

In case it helps, if you need to change the backend instead of rebooting you can change the setting, uninstall the plugin and reinstall it.

[Rysz]

Please install Network UPS Tools (NUT) for UNRAID by Rysz from Community Applications. The older plugins (including the one in the first post of this topic) are deprecated/now unsupported.

[Rysz]

22 hours ago, Kilrah said:

In case it helps, if you need to change the backend instead of rebooting you can change the setting, uninstall the plugin and reinstall it.

 

Yes, that's indeed possible, but I don't recommend this to anyone switching the backend because if you're switching the backend you're likely already having some kind of problems and not rebooting your system then adds another unpredictable variable to these already existing problems. Rebooting the system makes sure all files of the old backend are 100% gone from the system, as opposed to just uninstalling and reinstalling where we'll have to rely on the uninstallation routine being able to remove all those files.

[Hacky]

On 9/30/2023 at 10:00 AM, Rysz said:

 

Thanks for sharing this, I'm just curious what the use case for this would be, as opposed to running NUT in regular netserver setting without dummy-ups acting as a repeater and simply naming your UPS "qnapups" in the NUT settings.

 

I just did not want to name my UPS "qnapups" solely for the QNAP NAS.

 

But you are right. If one is okay with using QNAP's forced UPS name, it should probably be enough just using "qnapups" name in regular netserver without dummy-ups.

[ABEIDO]

Hi

 

Been having issues with UPS clients (servers thats using the UPS) power off when NUT plugin is updating. 

 

Am i right to think that changing the Kill UPS Power: Yes to No will solve this?

[Rysz]

11 minutes ago, ABEIDO said:

Hi

 

Been having issues with UPS clients (servers thats using the UPS) power off when NUT plugin is updating. 

 

Am i right to think that changing the Kill UPS Power: Yes to No will solve this?

 

This definitely shouldn't and doesn't happen with my NUT clients. Are your NUT clients somehow configured to shutdown when losing connection to the NUT master?

 

The update routine of the plugin just stops the NUT service (on the master) before updating but definitely does not trigger a shutdown scenario.

 

And no, "Kill UPS Power" just instructs your UPS to cut the battery power to all protected devices after running the shutdown sequence in case of a power outage.

 

Edited October 8, 2023 by Rysz

[ABEIDO]

1 hour ago, Rysz said:

 

This definitely shouldn't happen and doesn't happen with my NUT clients.

 

Are your NUT clients somehow configured to shutdown when losing connection to the NUT master? The update routine of the plugin just stops the NUT service (on the master) before updating but definitely does not trigger a shutdown scenario.

 

Have happend a couple of times and im not sure really why. Been reading logs a lot and it seems that the plugin was updated in the vicinity of the time it happend. Som maybe incorrect deduction by me.
 

Setup:

UPS: Back-UPS RS 900MI connected via USB to Unraid.

Unraid: NUT controls Unraid shutdown normally, power via UPS

Qnap: Builtin QNAP UPS feature is controlling shutdown, power via UPS

RPI(Home Assistant): NUT Integration to HA and automation thats shutdown server at 50% battery and then RPI(itself) at 20% battery, power via UPS.

Server(Windows): Shutdown via automation as above, power via UPS.

Router: No NUT, power via UPS

 

After looking closer the UPS kills power to all connected devices (Router, Unraid, RPI Home Assistant, Qnap NAS, Server Windows). It seems that Unraid gets shutdown command and turns of fast enough but the others shows logs or messages that points to that they werent shutdown correctly

 

The Home Assistant automation above wasnt triggerd by low battery so the server lost power. Windows logs confirm it too. So thats why i was thinking that the UPS kills the power outlets before the battery can even be drained by the machines and trigger the automation and so on. Can also add that i heard the UPS tick (switch between battery and power) a couple of times during this(no home power outage thou). It seems to run selftest every 2 weeks and thereyby the ticking and switching between battert and power.

 

Is there anything you see that im doing wrong?

 

Could the selftest affect NUT in some way(dont seem to be a way to disable it)?

 

Could the the kill ups power to no help(or what does it do)?

 

Logs/info

 

QNAP LOG(that shows that shutdown was incorrectly done):

Oct  8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: The system was not shut down properly last time.
Oct  8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: System started.
Oct  8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: [UPS] USB UPS device plugged in.
Oct  8 02:48:57 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: [Volume DataVol1, Pool 1] The file system is not clean.

 

NUT/UNRAID Log:
Oct  8 02:35:51 UNRAID upsmon[27897]: UPS [email protected]: administratively OFF or asleep
Oct  8 02:35:51 UNRAID upsd[27893]: Client [email protected] set FSD on UPS [qnapups]
Oct  8 02:35:51 UNRAID upsmon[27897]: Executing automatic power-fail shutdown
Oct  8 02:35:51 UNRAID upsmon[27897]: Auto logout and shutdown proceeding
Oct  8 02:35:56 UNRAID shutdown[3133]: shutting down for system halt
Oct  8 02:35:57 UNRAID init: Switching to runlevel: 0

Oct 8 02:35:57 UNRAID init: Trying to re-exec init

Oct 8 02:35:58 UNRAID kernel: mdcmd (36): nocheck cancel

Oct 8 02:35:59 UNRAID emhttpd: Spinning up all drives...

 

 Qnap settings

 

NUT Settings (i change Kill UPS Power this morning to NO)

Edited October 8, 2023 by ABEIDO

[Rysz]

2 hours ago, ABEIDO said:

 

Have happend a couple of times and im not sure really why. Been reading logs a lot and it seems that the plugin was updated in the vicinity of the time it happend. Som maybe incorrect deduction by me.
 

Setup:

Unraid: Qnap: Im letting NUT control Unraid normally, power via UPS

Qnap: Builtin UPS feature is controlling shutdown, power via UPS

RPI(Home Assistant): NUT Integration to HA and automation thats shutdown server at 50% battery and then RPI(itself) at 20% battery, power via UPS.

Server(Windows): Shutdown via automtion as above, power via UPS.

Router: No NUT, power via UPS

 

After looking closer the UPS kills power to all connected devices (Router, Unraid, RPI Home Assistant, Qnap NAS, Server Windows). It seems that Unraid gets shutdown command and turns of fast enough but the others shows logs or messages that points to that they werent shutdown correctly

 

The Home Assistant automation above wasnt triggerd by low battery so the server lost power. Windows logs confirm it too. So thats why i was thining that the UPS kills the power outlets before the battary can even be drained by the machines and trigger the automation and so on. Can also add that i heard the UPS tick (switch between battery and power) a couple of times during this(no home power outage thou).

 

Is there anything you see that im doing wrong and could the the kill ups power to no help(or what does it do)?

 

Logs/info

 

QNAP LOG(that shows that shutdown was incorrectly done):

Oct  8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: The system was not shut down properly last time.
Oct  8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: System started.
Oct  8 02:48:53 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: [UPS] USB UPS device plugged in.
Oct  8 02:48:57 QNAP qlogd[10732]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: [Volume DataVol1, Pool 1] The file system is not clean.

 

NUT/UNRAID Log:
Oct  8 02:35:51 UNRAID upsmon[27897]: UPS [email protected]: administratively OFF or asleep
Oct  8 02:35:51 UNRAID upsd[27893]: Client [email protected] set FSD on UPS [qnapups]
Oct  8 02:35:51 UNRAID upsmon[27897]: Executing automatic power-fail shutdown
Oct  8 02:35:51 UNRAID upsmon[27897]: Auto logout and shutdown proceeding
Oct  8 02:35:56 UNRAID shutdown[3133]: shutting down for system halt
Oct  8 02:35:57 UNRAID init: Switching to runlevel: 0

Oct 8 02:35:57 UNRAID init: Trying to re-exec init

Oct 8 02:35:58 UNRAID kernel: mdcmd (36): nocheck cancel

Oct 8 02:35:59 UNRAID emhttpd: Spinning up all drives...

 

 Qnap settings

 

NUT Settings (i change Kill UPS Power this morning to NO)

 

OK this is quite an advanced setup you've got there, so let's see.

 

Definitely before this happens, some kind of power problem occurs (due to mains power loss or mains power condition like voltage/frequency spike as seen in brownouts) OR your UPS is reporting such a state to NUT falsely (due to defective UPS, driver problem ...). So NUT is receiving information from your UPS that makes it consider your UPS to be in a critical state, triggering an immediate shutdown despite any of your configured NUT settings (e.g. "Runtime Left" as "Shutdown Mode").

 

Interesting is, your UPS is only reporting a UPS "OFF" event to NUT here:

Oct  8 02:35:51 UNRAID upsmon[27897]: UPS [email protected]: administratively OFF or asleep

 

But are there any more log lines before this one indicating that your UPS is going on battery power at some point? Please post any NUT log lines before this one, if there are any. Because this line on its own makes no sense to trigger such a critical situation - your UPS would need to be on battery for a shutdown sequence as below to occur.

 

Before proceeding to initiate a shutdown sequence (FSD) thinking your UPS is critical:

Oct  8 02:35:51 UNRAID upsd[27893]: Client [email protected] set FSD on UPS [qnapups]

We need to find out why NUT thinks your UPS is critical, this usually only happens when your UPS is both on battery and the UPS battery is almost depleted at the same time. But there's no indication from your logs (just from the inverter clicking sounds) that your UPS is in fact on battery, that's what I don't understand. Plus, for your UPS to reach such a low battery (critical) state faster than your UPS master & clients can shutdown would mean either the UPS battery is severely overloaded (too much power draw) or on the verge of dying (due to old age or defects). Both should be reported by your UPS somehow, so this wouldn't happen out of the blue (unless something was defective).

 

In such a shutdown sequence NUT (by default) waits max. 15 seconds for your clients to shutdown. If your clients don't shutdown within those 15 seconds, it proceeds to continue to shutdown the UNRAID server. Normally this wouldn't have negative effects on your clients shutdown sequences, but you had "Kill UPS Power" set to "Yes". So after UNRAID shutdown is completed, it kills the power to all your clients even if they're not done with their own shutdown sequences yet - this is what caused your unclean shutdowns there.

 

With "Kill UPS Power" set to "Yes" one needs to make sure that the clients start their shutdown sequences earlier than the master and also have sufficient time to shutdown before the master starts shutting down and cuts the power. This is, of course, not possible when your UPS suddenly goes critical for reasons unknown - so we'll need to set this to "No" for now.

 

So where to go from all this information?

It's not from updating the plugin, definitely, but rather something happening with your UPS. You hear the inverter clicking, so the UPS hardware is doing something at that stage (which is not NUT-caused).

 

First of all, keep "Kill UPS Power" set to "No" until we figure out what is going on with your UPS. This should at least solve the unclean shutdowns for now, but you'll still see your devices shutting down (though gracefully) when your UPS is going into such a sudden critical state. We need to figure out what's happening with your UPS hardware.

 

Quote

Can also add that i heard the UPS tick (switch between battery and power) a couple of times during this(no home power outage thou).

 

So if there's no power outage this could either be your UPS testing its battery, conditioning power (because of voltage/frequency spikes) or your UPS/UPS battery being defective. A battery test or power conditioning should not cause a NUT critical state, unless the battery is almost dead in the first place and does not even survive that short time on battery power in combination with the load connected. Did you see any lights flickering in your house when this was happening?

 

First I would make sure your UPS is not somehow overloaded (too many watts for too little battery). If that's not the case, I'd attempt to switch out the UPS batteries, that being the cheapest solution. Especially if your UPS batteries are already older, changing them can be magic to solving very weird problems.

 

If the problem persists even then I'd consider the UPS defective and have it checked by the vendor. If you're still in warranty for your UPS I'd definitely contact the vendor and get the UPS and UPS battery checked.

 

All of this is, of course, under the assumption that your UPS is generally compatible with NUT. Please do also cross-check with the hardware list on the NUT website for reference. Sometimes searching for your UPS model together with NUT on Google can also reveal some issues other people with the same model were previously having. But overall I do still think something hardware-related is happening (regardless of NUT) because your UPS is also making the clicking (inverter) noises whenever the problem occurs.

 

P.S. Also, I'd generally advise against using "Runtime Left" as "Shutdown Mode" as it's highly dependent on the state of both your UPS battery and UPS reported variables. It's the least reliable out of the three "Shutdown Mode"s, so it might be worth trying with another "Shutdown Mode", especially when you're already having some problems and if your UPS battery is already older.

 

Edited October 8, 2023 by Rysz

[ABEIDO]

1 hour ago, Rysz said:

 

OK this is quite an advanced setup you've got there, so let's see.

 

Definitely before this happens, some kind of power problem occurs (due to mains power loss or mains power condition like voltage/frequency spike as seen in brownouts) OR your UPS is reporting such a state to NUT falsely (due to defective UPS, driver problem ...). So NUT is receiving information from your UPS that makes it consider your UPS to be in a critical state, triggering an immediate shutdown despite any of your configured NUT settings (e.g. "Runtime Left" as "Shutdown Mode").

 

Interesting is, your UPS is only reporting a UPS "OFF" event to NUT here:

Oct  8 02:35:51 UNRAID upsmon[27897]: UPS [email protected]: administratively OFF or asleep

 

But are there any more log lines before this one indicating that your UPS is going on battery power at some point? Please post any NUT log lines before this one, if there are any. Because this line on its own makes no sense to trigger such a critical situation - your UPS would need to be on battery for a shutdown sequence as below to occur.

 

Before proceeding to initiate a shutdown sequence (FSD) thinking your UPS is critical:

Oct  8 02:35:51 UNRAID upsd[27893]: Client [email protected] set FSD on UPS [qnapups]

We need to find out why NUT thinks your UPS is critical, this usually only happens when your UPS is both on battery and the UPS battery is almost depleted at the same time. But there's no indication from your logs (just from the inverter clicking sounds) that your UPS is in fact on battery, that's what I don't understand. Plus, for your UPS to reach such a low battery (critical) state faster than your UPS master & clients can shutdown would mean either the UPS battery is severely overloaded (too much power draw) or on the verge of dying (due to old age or defects). Both should be reported by your UPS somehow, so this wouldn't happen out of the blue (unless something was defective).

 

In such a shutdown sequence NUT (by default) waits max. 15 seconds for your clients to shutdown. If your clients don't shutdown within those 15 seconds, it proceeds to continue to shutdown the UNRAID server. Normally this wouldn't have negative effects on your clients shutdown sequences, but you had "Kill UPS Power" set to "Yes". So after UNRAID shutdown is completed, it kills the power to all your clients even if they're not done with their own shutdown sequences yet - this is what caused your unclean shutdowns there.

 

With "Kill UPS Power" set to "Yes" one needs to make sure that the clients start their shutdown sequences earlier than the master and also have sufficient time to shutdown before the master starts shutting down and cuts the power. This is, of course, not possible when your UPS suddenly goes critical for reasons unknown - so we'll need to set this to "No" for now.

 

So where to go from all this information?

It's not from updating the plugin, definitely, but rather something happening with your UPS. You hear the inverter clicking, so the UPS hardware is doing something at that stage (which is not NUT-caused).

 

First of all, keep "Kill UPS Power" set to "No" until we figure out what is going on with your UPS. This should at least solve the unclean shutdowns for now, but you'll still see your devices shutting down (though gracefully) when your UPS is going into such a sudden critical state. We need to figure out what's happening with your UPS hardware.

 

 

So if there's no power outage this could either be your UPS testing its battery, conditioning power (because of voltage/frequency spikes) or your UPS/UPS battery being defective. A battery test or power conditioning should not cause a NUT critical state, unless the battery is almost dead in the first place and does not even survive the short time on battery power in combination with the load connected. Did you see any lights flickering in your house when this was happening?

 

First I would make sure your UPS is not somehow overloaded (too many watts for too little battery). If that's not the case, I'd attempt to switch out the UPS batteries, that being the cheapest solution. Especially if your UPS batteries are already older, changing them can be magic to solving very weird problems.

 

If the problem persists even then I'd consider the UPS defective and have it checked by the vendor. If you're still in warranty for your UPS I'd definitely contact the vendor and get the UPS and UPS battery checked.

 

 

Firstly, not many takes the time you took here. So a massive thanks for that :).

 

Im kinda torn were the problem is as explained below. But in short the UPS new, tests ok and only happens during 2 week auto selftest. 

 

Auto Selftest:

It seems that the problem only occur during auto selftest thats done every 2 weeks. Havent been able to find any way to disable those. They are done at start aswell but no problem then with either blinking or power offs(hard to see as devices are off as ups is off aswell).

 

Blinking lights:

When i got the ups (first setup) i had some issues with blinking monitor when inverter acted and that was plugged into same area as UPS. This went away as i think i changed Input Sensitivity to low. No blinking during my own testing at all. 

 

Age/wear:

My UPS is kinda new is less than a year old (even warranty on both batteries and ups) and is in a good location with normal temps. All selftest reports ok. 

 

Overload:

Average usage is 80-100w and it should be able to handle 540w and havent been close to that. My homelab is based on lower power usage so no fancy big machines (Optiplex x2, RPI, router and QNAP Intel Atom)

 

Load history

 

Test:

Have done full test to make sure all devices and automations works fine before and it was working, had battery runtime on about 40-45 min before it was depleted. Tested a quickie now so i unplugged power to UPS with everything up and running as normal and it worked as expected. Log below

 

QNAP power outtage test
Oct 8 15:11:04 NAS qlogd[9991]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: Power loss detected on UPS. System would be shutdown after 10 minute(s).

Oct 8 15:11:37 NAS qlogd[9991]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: Power has returned to UPS. Canceling shutdown.

 

UNRAID power outtage test

Oct 8 15:10:40 UNRAID upsmon[3260]:

UPS [email protected] on battery

Oct 8 15:11:35 UNRAID upsmon[3260]: UPS [email protected] on line power

 

 

Full log:

Theres nothing close before that log, earlier there were unrelated logs imo. Regarding Stop running nchan processes i think its related to other problems with a container in below thread. And this error is always getting logged and i would have issue all the time with the NUT ot that was causing it. https://forums.unraid.net/topic/141974-support-fork-unraid-api-re/?do=findComment&comment=1314157

 

Quote

Oct  8 00:44:48 UNRAID webGUI: Successful login user root from XXXXX
Oct  8 00:45:05 UNRAID monitor: Stop running nchan processes
Oct  8 00:45:38 UNRAID monitor: Stop running nchan processes
Oct  8 00:46:11 UNRAID monitor: Stop running nchan processes
Oct  8 00:49:40 UNRAID kernel: br-58b51fbafe10: port 18(vethfe385d5) entered disabled state
Oct  8 00:49:40 UNRAID kernel: veth3bdeac6: renamed from eth0
Oct  8 00:49:40 UNRAID kernel: br-58b51fbafe10: port 18(vethfe385d5) entered disabled state
Oct  8 00:49:40 UNRAID kernel: device vethfe385d5 left promiscuous mode
Oct  8 00:49:40 UNRAID kernel: br-58b51fbafe10: port 18(vethfe385d5) entered disabled state
Oct  8 00:58:14 UNRAID kernel: br-58b51fbafe10: port 18(veth52b59e3) entered blocking state
Oct  8 00:58:14 UNRAID kernel: br-58b51fbafe10: port 18(veth52b59e3) entered disabled state
Oct  8 00:58:14 UNRAID kernel: device veth52b59e3 entered promiscuous mode
Oct  8 00:58:14 UNRAID kernel: eth0: renamed from vethe1b859f
Oct  8 00:58:14 UNRAID kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth52b59e3: link becomes ready
Oct  8 00:58:14 UNRAID kernel: br-58b51fbafe10: port 18(veth52b59e3) entered blocking state
Oct  8 00:58:14 UNRAID kernel: br-58b51fbafe10: port 18(veth52b59e3) entered forwarding state
Oct  8 00:58:17 UNRAID webGUI: Successful login user root from XXXXX
Oct  8 01:00:18 UNRAID monitor: Stop running nchan processes
Oct  8 01:00:51 UNRAID monitor: Stop running nchan processes
Oct  8 01:01:24 UNRAID monitor: Stop running nchan processes
Oct  8 01:01:57 UNRAID monitor: Stop running nchan processes
Oct  8 01:02:30 UNRAID monitor: Stop running nchan processes
Oct  8 01:03:03 UNRAID monitor: Stop running nchan processes
Oct  8 01:03:41 UNRAID kernel: vethe1b859f: renamed from eth0
Oct  8 01:03:41 UNRAID kernel: br-58b51fbafe10: port 18(veth52b59e3) entered disabled state
Oct  8 01:03:41 UNRAID kernel: br-58b51fbafe10: port 18(veth52b59e3) entered disabled state
Oct  8 01:03:41 UNRAID kernel: device veth52b59e3 left promiscuous mode
Oct  8 01:03:41 UNRAID kernel: br-58b51fbafe10: port 18(veth52b59e3) entered disabled state
Oct  8 01:06:03 UNRAID webGUI: Successful login user root from 10.20.30.41
Oct  8 01:06:31 UNRAID kernel: br-58b51fbafe10: port 18(veth68a62f0) entered blocking state
Oct  8 01:06:31 UNRAID kernel: br-58b51fbafe10: port 18(veth68a62f0) entered disabled state
Oct  8 01:06:31 UNRAID kernel: device veth68a62f0 entered promiscuous mode
Oct  8 01:06:32 UNRAID kernel: eth0: renamed from veth8e90f61
Oct  8 01:06:32 UNRAID kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth68a62f0: link becomes ready
Oct  8 01:06:32 UNRAID kernel: br-58b51fbafe10: port 18(veth68a62f0) entered blocking state
Oct  8 01:06:32 UNRAID kernel: br-58b51fbafe10: port 18(veth68a62f0) entered forwarding state
Oct  8 01:06:34 UNRAID webGUI: Successful login user root from XXXXX
Oct  8 01:15:14 UNRAID ool www[20963]: Successful logout user root from XXXXX
Oct  8 01:15:18 UNRAID webGUI: Successful login user root from XXXXX
Oct  8 01:15:37 UNRAID monitor: Stop running nchan processes
Oct  8 01:16:10 UNRAID monitor: Stop running nchan processes
Oct  8 01:16:43 UNRAID monitor: Stop running nchan processes
Oct  8 01:17:16 UNRAID monitor: Stop running nchan processes
Oct  8 01:17:49 UNRAID monitor: Stop running nchan processes
Oct  8 01:18:22 UNRAID monitor: Stop running nchan processes
Oct  8 01:18:56 UNRAID monitor: Stop running nchan processes
Oct  8 01:19:29 UNRAID monitor: Stop running nchan processes
Oct  8 01:20:02 UNRAID monitor: Stop running nchan processes
Oct  8 01:20:35 UNRAID monitor: Stop running nchan processes
Oct  8 01:21:08 UNRAID monitor: Stop running nchan processes
Oct  8 01:21:41 UNRAID monitor: Stop running nchan processes
Oct  8 01:22:14 UNRAID monitor: Stop running nchan processes
Oct  8 01:22:48 UNRAID monitor: Stop running nchan processes
Oct  8 01:23:21 UNRAID monitor: Stop running nchan processes
Oct  8 01:23:54 UNRAID monitor: Stop running nchan processes
Oct  8 01:24:27 UNRAID monitor: Stop running nchan processes
Oct  8 01:25:00 UNRAID monitor: Stop running nchan processes
Oct  8 01:25:33 UNRAID monitor: Stop running nchan processes
Oct  8 01:26:07 UNRAID monitor: Stop running nchan processes
Oct  8 01:26:40 UNRAID monitor: Stop running nchan processes
Oct  8 01:26:57 UNRAID webGUI: Successful login user root from XXXXX
Oct  8 02:03:43 UNRAID monitor: Stop running nchan processes
Oct  8 02:04:16 UNRAID monitor: Stop running nchan processes
Oct  8 02:04:50 UNRAID monitor: Stop running nchan processes
Oct  8 02:05:23 UNRAID monitor: Stop running nchan processes
Oct  8 02:05:56 UNRAID monitor: Stop running nchan processes
Oct  8 02:06:29 UNRAID monitor: Stop running nchan processes
Oct  8 02:07:02 UNRAID monitor: Stop running nchan processes
Oct  8 02:07:35 UNRAID monitor: Stop running nchan processes
Oct  8 02:08:08 UNRAID monitor: Stop running nchan processes
Oct  8 02:08:42 UNRAID monitor: Stop running nchan processes
Oct  8 02:09:15 UNRAID monitor: Stop running nchan processes
Oct  8 02:09:48 UNRAID monitor: Stop running nchan processes
Oct  8 02:10:21 UNRAID monitor: Stop running nchan processes
Oct  8 02:10:54 UNRAID monitor: Stop running nchan processes
Oct  8 02:11:27 UNRAID monitor: Stop running nchan processes
Oct  8 02:12:01 UNRAID monitor: Stop running nchan processes
Oct  8 02:12:34 UNRAID monitor: Stop running nchan processes
Oct  8 02:13:07 UNRAID monitor: Stop running nchan processes
Oct  8 02:13:40 UNRAID monitor: Stop running nchan processes
Oct  8 02:14:13 UNRAID monitor: Stop running nchan processes
Oct  8 02:14:46 UNRAID monitor: Stop running nchan processes
Oct  8 02:15:19 UNRAID monitor: Stop running nchan processes
Oct  8 02:15:53 UNRAID monitor: Stop running nchan processes
Oct  8 02:16:26 UNRAID monitor: Stop running nchan processes
Oct  8 02:16:59 UNRAID monitor: Stop running nchan processes
Oct  8 02:17:32 UNRAID monitor: Stop running nchan processes
Oct  8 02:18:05 UNRAID monitor: Stop running nchan processes
Oct  8 02:18:38 UNRAID monitor: Stop running nchan processes
Oct  8 02:19:11 UNRAID monitor: Stop running nchan processes
Oct  8 02:19:45 UNRAID monitor: Stop running nchan processes
Oct  8 02:20:18 UNRAID monitor: Stop running nchan processes
Oct  8 02:20:51 UNRAID monitor: Stop running nchan processes
Oct  8 02:21:24 UNRAID monitor: Stop running nchan processes
Oct  8 02:21:57 UNRAID monitor: Stop running nchan processes
Oct  8 02:22:30 UNRAID monitor: Stop running nchan processes
Oct  8 02:23:04 UNRAID monitor: Stop running nchan processes
Oct  8 02:23:37 UNRAID monitor: Stop running nchan processes
Oct  8 02:24:10 UNRAID monitor: Stop running nchan processes
Oct  8 02:24:43 UNRAID monitor: Stop running nchan processes
Oct  8 02:25:16 UNRAID monitor: Stop running nchan processes
Oct  8 02:25:49 UNRAID monitor: Stop running nchan processes
Oct  8 02:26:22 UNRAID monitor: Stop running nchan processes
Oct  8 02:26:56 UNRAID monitor: Stop running nchan processes
Oct  8 02:27:29 UNRAID monitor: Stop running nchan processes
Oct  8 02:28:02 UNRAID monitor: Stop running nchan processes
Oct  8 02:28:35 UNRAID monitor: Stop running nchan processes
Oct  8 02:29:08 UNRAID monitor: Stop running nchan processes
Oct  8 02:29:41 UNRAID monitor: Stop running nchan processes
Oct  8 02:30:14 UNRAID monitor: Stop running nchan processes
Oct  8 02:30:48 UNRAID monitor: Stop running nchan processes
Oct  8 02:31:21 UNRAID monitor: Stop running nchan processes
Oct  8 02:31:54 UNRAID monitor: Stop running nchan processes
Oct  8 02:32:27 UNRAID monitor: Stop running nchan processes
Oct  8 02:33:00 UNRAID monitor: Stop running nchan processes
Oct  8 02:33:33 UNRAID monitor: Stop running nchan processes
Oct  8 02:34:07 UNRAID monitor: Stop running nchan processes
Oct  8 02:34:40 UNRAID monitor: Stop running nchan processes
Oct  8 02:35:13 UNRAID monitor: Stop running nchan processes
Oct  8 02:35:46 UNRAID monitor: Stop running nchan processes
Oct  8 02:35:51 UNRAID upsmon[27897]: UPS [email protected]: administratively OFF or asleep
Oct  8 02:35:51 UNRAID upsd[27893]: Client [email protected] set FSD on UPS [qnapups]
Oct  8 02:35:51 UNRAID upsmon[27897]: Executing automatic power-fail shutdown
Oct  8 02:35:51 UNRAID upsmon[27897]: Auto logout and shutdown proceeding
Oct  8 02:35:56 UNRAID shutdown[3133]: shutting down for system halt
Oct  8 02:35:57 UNRAID init: Switching to runlevel: 0

and so on...

 

 

Edited October 8, 2023 by ABEIDO

[Rysz]

1 hour ago, ABEIDO said:

 

Firstly, not many takes the time you took here. So a massive thanks for that :).

 

Im kinda torn were the problem is as explained below. But in short the UPS new, tests ok and only happens during 2 week auto selftest. 

 

Auto Selftest:

It seems that the problem only occur during auto selftest thats done every 2 weeks. Havent been able to find any way to disable those. They are done at start aswell but no problem then with either blinking or power offs(hard to see as devices are off as ups is off aswell).

 

Blinking lights:

When i got the ups (first setup) i had some issues with blinking monitor when inverter acted and that was plugged into same area as UPS. This went away as i think i changed Input Sensitivity to low. No blinking during my own testing at all. 

 

Age/wear:

My UPS is kinda new is less than a year old (even warranty on both batteries and ups) and is in a good location with normal temps. All selftest reports ok. 

 

Overload:

Average usage is 80-100w and it should be able to handle 540w and havent been close to that. My homelab is based on lower power usage so no fancy big machines (Optiplex x2, RPI, router and QNAP Intel Atom)

 

Load history

 

Test:

Have done full test to make sure all devices and automations works fine before and it was working, had battery runtime on about 40-45 min before it was depleted. Tested a quickie now so i unplugged power to UPS with everything up and running as normal and it worked as expected. Log below

 

QNAP power outtage test
Oct 8 15:11:04 NAS qlogd[9991]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: Power loss detected on UPS. System would be shutdown after 10 minute(s).

Oct 8 15:11:37 NAS qlogd[9991]: event log: Users: System, Source IP: 127.0.0.1, Computer name: localhost, Content: Power has returned to UPS. Canceling shutdown.

 

UNRAID power outtage test

Oct 8 15:10:40 UNRAID upsmon[3260]:

UPS [email protected] on battery

Oct 8 15:11:35 UNRAID upsmon[3260]: UPS [email protected] on line power

 

 

Full log:

Theres nothing close before that log, earlier there were unrelated logs imo. Regarding Stop running nchan processes i think its related to other problems with a container in below thread. And this error is always getting logged and i would have issue all the time with the NUT ot that was causing it. https://forums.unraid.net/topic/141974-support-fork-unraid-api-re/?do=findComment&comment=1314157

 

and so on...

 

 

 

OK this is super useful information so thanks for that so far. UPS inverter clicking during self-tests is normal, so that in combination with the other information provided about the UPS hardware's state also makes me think more in direction of a configuration or software issue now.

 

One major problem I've identified with the configuration is that you're using the same usernames for "NUT Monitor Username" and "NUT Slave Username", but those can never be the same because they come with a different set of permissions each. "NUT Monitor Username" is the one the NUT master will use, "NUT Slave Username" is the one your NUT clients will use. Please change your "NUT Monitor Username" to a different username, you won't need to change any settings with the clients. This will make sure the NUT services can distinguish between who is NUT master and who is NUT slave (client), that's really important for functionality.

 

I've read about some UPS only reporting a limited set of variables to NUT during self-tests, so it's possible that during these self-tests the "Runtime Left" variable becomes either unavailable or zero for a few (milli-)seconds while the inverter switches between line power and battery power for testing (that's the clicking you hear).

 

This could (in theory) lead to NUT seeing the UPS on battery power during the testing and at the same time the "Runtime Left" variable unavailable and/or below your configured 15 minutes - resulting in the false shutdown sequence with NUT thinking that it's a power loss scenario.

 

So I'd suggest doing this:

• Change "NUT Monitor Username" to something else.
• Change "Shutdown Mode" to "Time On Battery" (for test purposes)
• Set "Time on Battery before Shutdown (minutes):" to 5-6 minutes (for test purposes)
• Set "Kill UPS Power" to "No"

 

If you can, trigger a manual self-test of the UPS and see if the problem still occurs.

 

You can also choose "Battery Charge" as "Shutdown Mode", it's still better than "Runtime Left", but "Time On Battery" is mostly independent from UPS-reported variables so it's best for testing now.

 

In general I'd always advise to using either "Battery Charge" or "Time on Battery", rather than "Runtime Left", because "Runtime Left" is the least predictable and trustworthy of the different "Shutdown Mode"s.

 

The reason is reported UPS runtime can fluctuate a lot depending on UPS and UPS battery and many UPS vendors do not have clean implementations of this variable.

 

Edited October 8, 2023 by Rysz

[itimpi]

On 9/30/2023 at 9:39 AM, Alcapone001 said:

As an aside any reason why Unraid mainly supports APC UPS only. Sponsorship? 

APC are quite common and are well regarded, and many suppliers (e.g. the CyberPower UPS I use) are APC compatible at the software level.    There is also the issue of which UPS drivers have been incorporated as standard into the Linux kernel so it is easy to include support for them.

[ABEIDO]

1 hour ago, Rysz said:

 

OK this is super useful information so thanks for that so far. UPS inverter clicking during self-tests is normal, so that in combination with the other information provided about the UPS hardware's state also makes me think more in direction of a configuration or software issue now.

 

One major problem I've identified with the configuration is that you're using the same usernames for "NUT Monitor Username" and "NUT Slave Username", but those can never be the same because they come with a different set of permissions each. "NUT Monitor Username" is the one the NUT master will use, "NUT Slave Username" is the one your NUT clients will use. Please change your "NUT Monitor Username" to a different username, you won't need to change any settings with the clients. This will make sure the NUT services can distinguish between who is NUT master and who is NUT slave (client), that's really important for functionality.

 

I've read about some UPS only reporting a limited set of variables to NUT during self-tests, so it's possible that during these self-tests the "Runtime Left" variable becomes either unavailable or zero for a few (milli-)seconds while the inverter switches between line power and battery power for testing (that's the clicking you hear).

 

This could (in theory) lead to NUT seeing the UPS on battery power during the testing and at the same time the "Runtime Left" variable unavailable and/or below your configured 15 minutes - resulting in the false shutdown sequence with NUT thinking that it's a power loss scenario.

 

So I'd suggest doing this:

• Change "NUT Monitor Username" to something else.
• Change "Shutdown Mode" to "Time On Battery" (for test purposes)
• Set "Time on Battery before Shutdown (minutes):" to 5-6 minutes (for test purposes)
• Set "Kill UPS Power" to "No"

 

If you can, trigger a manual self-test of the UPS and see if the problem still occurs.

 

You can also choose "Battery Charge" as "Shutdown Mode", it's still better than "Runtime Left", but "Time On Battery" is mostly independent from UPS-reported variables so it's best for testing now.

 

In general I'd always advise to using either "Battery Charge" or "Time on Battery", rather than "Runtime Left", because "Runtime Left" is the least predictable and trustworthy of the different "Shutdown Mode"s.

 

The reason is reported UPS runtime can fluctuate a lot depending on UPS and UPS battery and many UPS vendors do not have clean implementations of this variable.

 

 

I didnt know that with slave and master users, good info. Have changed that now.

 

The manual test acts the same as the schedueled in regards of symptons which i didnt thought was the case, so i have a way of testing solutions now. Btw i tested without Qnap running, didnt want to messup the NAS. And problems is the same even the load now only is 34w when ups is off.

 

Test 1

-Did a test before but with only Kill UPS Power change to No.

Only Unraid shuts down (correctly thou as it always had) but it does it directly. So not staying on until set rule.

 

Test 2

-Tested with all the suggested changes. Unraid shuts down (correctly thou as it always had) So not staying on until set rule. So same as before.

 

Test 3

-Tested with all the suggested changes but with Shutdown Mode Battery Level . Unraid shuts down (correctly thou as it always had). So not staying on until set rule. So same as before.

 

Saw below just before it turned off both times.

1

 

2

 

In Home Assistant (just as extra info). Yellow status name is same status as above 2. Black part is when unraid is off.

 

 

So still same issue but without the powerloss for the connected devices. When i thinkm about it i couldnt have had these problem before on the old repo. I mean i would remember that my nas/unraid/server was down randomly every 2 weeks as i cannot disable auto selftest (what i have found)

 

Only other ui option i havent touched is:

and

 

Are those of any importance in regads to the problem?

 

 

Some Log from a test.

 

Quote

Octt  8 17:17:27 UNRAID ool www[15552]: /usr/local/emhttp/plugins/nut/scripts/stop
Oct  8 17:17:28 UNRAID root: Writing NUT configuration...
Oct  8 17:17:29 UNRAID flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update
Oct  8 17:17:30 UNRAID root: Updating permissions for NUT...
Oct  8 17:17:30 UNRAID root: Checking if the NUT Runtime Statistics Module should be enabled...
Oct  8 17:17:30 UNRAID root: Disabling the NUT Runtime Statistics Module...
Oct  8 17:17:31 UNRAID root: Stopping the NUT services... 
Oct  8 17:17:31 UNRAID upsd[8243]: mainloop: Interrupted system call
Oct  8 17:17:31 UNRAID upsd[8243]: Signal 15: exiting
Oct  8 17:17:31 UNRAID root: Network UPS Tools upsd 2.8.0.1
Oct  8 17:17:31 UNRAID root: Network UPS Tools upsmon 2.8.0.1
Oct  8 17:17:31 UNRAID upsmon[8247]: Signal 15: exiting
Oct  8 17:17:31 UNRAID upsmon[8246]: upsmon parent: read
Oct  8 17:17:31 UNRAID usbhid-ups[8212]: WARNING: send_to_all: write 34 bytes to socket 16 failed (ret=-1), disconnecting: Broken pipe
Oct  8 17:17:33 UNRAID usbhid-ups[8212]: Signal 15: exiting
Oct  8 17:17:34 UNRAID root: Network UPS Tools - UPS driver controller 2.8.0.1
Oct  8 17:17:43 UNRAID ool www[15551]: /usr/local/emhttp/plugins/nut/scripts/stop
Oct  8 17:17:44 UNRAID root: Writing NUT configuration...
Oct  8 17:17:46 UNRAID root: Updating permissions for NUT...
Oct  8 17:17:46 UNRAID root: Checking if the NUT Runtime Statistics Module should be enabled...
Oct  8 17:17:46 UNRAID root: Disabling the NUT Runtime Statistics Module...
Oct  8 17:17:47 UNRAID root: Stopping the NUT services... 
Oct  8 17:17:49 UNRAID root: Network UPS Tools - UPS driver controller 2.8.0.1
Oct  8 17:18:06 UNRAID ool www[17328]: /usr/local/emhttp/plugins/nut/scripts/stop
Oct  8 17:18:07 UNRAID root: Writing NUT configuration...
Oct  8 17:18:08 UNRAID root: Updating permissions for NUT...
Oct  8 17:18:08 UNRAID root: Checking if the NUT Runtime Statistics Module should be enabled...
Oct  8 17:18:08 UNRAID root: Disabling the NUT Runtime Statistics Module...
Oct  8 17:18:09 UNRAID root: Stopping the NUT services... 
Oct  8 17:18:11 UNRAID root: Network UPS Tools - UPS driver controller 2.8.0.1
Oct  8 17:18:23 UNRAID ool www[17320]: /usr/local/emhttp/plugins/nut/scripts/start
Oct  8 17:18:24 UNRAID root: Writing NUT configuration...
Oct  8 17:18:26 UNRAID root: Updating permissions for NUT...
Oct  8 17:18:26 UNRAID root: Checking if the NUT Runtime Statistics Module should be enabled...
Oct  8 17:18:26 UNRAID root: Disabling the NUT Runtime Statistics Module...
Oct  8 17:18:27 UNRAID root: Using subdriver: APC HID 0.100
Oct  8 17:18:27 UNRAID root: Network UPS Tools - Generic HID driver 0.52 (2.8.0.1)
Oct  8 17:18:27 UNRAID root: USB communication driver (libusb 1.0) 0.46
Oct  8 17:18:27 UNRAID usbhid-ups[19923]: Startup successful
Oct  8 17:18:27 UNRAID usbhid-ups[19923]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
Oct  8 17:18:27 UNRAID root: Network UPS Tools - UPS driver controller 2.8.0.1
Oct  8 17:18:28 UNRAID upsd[20052]: listening on 0.0.0.0 port 3493
Oct  8 17:18:28 UNRAID upsd[20052]: Connected to UPS [qnapups]: usbhid-ups-qnapups
Oct  8 17:18:28 UNRAID upsd[20052]: Found 1 UPS defined in ups.conf
Oct  8 17:18:28 UNRAID usbhid-ups[19923]: sock_connect: enabling asynchronous mode (auto)
Oct  8 17:18:28 UNRAID upsd[20053]: Startup successful
Oct  8 17:18:28 UNRAID upsd[20053]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
Oct  8 17:18:28 UNRAID upsmon[20056]: Startup successful
Oct  8 17:18:28 UNRAID upsmon[20057]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
Oct  8 17:18:28 UNRAID upsd[20053]: User [email protected] logged into UPS [qnapups]
Oct  8 17:18:29 UNRAID flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update
Oct  8 17:19:49 UNRAID ool www[23606]: /usr/local/emhttp/plugins/nut/scripts/stop
Oct  8 17:19:50 UNRAID root: Writing NUT configuration...
Oct  8 17:19:52 UNRAID root: Updating permissions for NUT...
Oct  8 17:19:52 UNRAID root: Checking if the NUT Runtime Statistics Module should be enabled...
Oct  8 17:19:52 UNRAID root: Disabling the NUT Runtime Statistics Module...
Oct  8 17:19:53 UNRAID root: Stopping the NUT services... 
Oct  8 17:19:53 UNRAID upsd[20053]: mainloop: Interrupted system call
Oct  8 17:19:53 UNRAID upsd[20053]: Signal 15: exiting
Oct  8 17:19:53 UNRAID root: Network UPS Tools upsd 2.8.0.1
Oct  8 17:19:53 UNRAID upsmon[20057]: Signal 15: exiting
Oct  8 17:19:53 UNRAID root: Network UPS Tools upsmon 2.8.0.1
Oct  8 17:19:53 UNRAID upsmon[20056]: upsmon parent: read
Oct  8 17:19:53 UNRAID usbhid-ups[19923]: WARNING: send_to_all: write 34 bytes to socket 16 failed (ret=-1), disconnecting: Broken pipe
Oct  8 17:19:55 UNRAID usbhid-ups[19923]: Signal 15: exiting
Oct  8 17:19:56 UNRAID root: Network UPS Tools - UPS driver controller 2.8.0.1
Oct  8 17:20:11 UNRAID ool www[23608]: /usr/local/emhttp/plugins/nut/scripts/start
Oct  8 17:20:12 UNRAID root: Writing NUT configuration...
Oct  8 17:20:14 UNRAID root: Updating permissions for NUT...
Oct  8 17:20:14 UNRAID root: Checking if the NUT Runtime Statistics Module should be enabled...
Oct  8 17:20:14 UNRAID root: Disabling the NUT Runtime Statistics Module...
Oct  8 17:20:15 UNRAID root: Using subdriver: APC HID 0.100
Oct  8 17:20:15 UNRAID root: Network UPS Tools - Generic HID driver 0.52 (2.8.0.1)
Oct  8 17:20:15 UNRAID root: USB communication driver (libusb 1.0) 0.46
Oct  8 17:20:15 UNRAID usbhid-ups[26260]: Startup successful
Oct  8 17:20:15 UNRAID usbhid-ups[26260]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
Oct  8 17:20:15 UNRAID root: Network UPS Tools - UPS driver controller 2.8.0.1
Oct  8 17:20:16 UNRAID upsd[26294]: listening on 0.0.0.0 port 3493
Oct  8 17:20:16 UNRAID upsd[26294]: Connected to UPS [qnapups]: usbhid-ups-qnapups
Oct  8 17:20:16 UNRAID usbhid-ups[26260]: sock_connect: enabling asynchronous mode (auto)
Oct  8 17:20:16 UNRAID upsd[26294]: Found 1 UPS defined in ups.conf
Oct  8 17:20:16 UNRAID upsd[26295]: Startup successful
Oct  8 17:20:16 UNRAID upsd[26295]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
Oct  8 17:20:16 UNRAID upsmon[26301]: Startup successful
Oct  8 17:20:16 UNRAID upsmon[26302]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
Oct  8 17:20:16 UNRAID upsd[26295]: User [email protected] logged into UPS [qnapups]
Oct  8 17:21:36 UNRAID kernel: TCP: request_sock_TCP: Possible SYN flooding on port 8181. Sending cookies.  Check SNMP counters.
Oct  8 17:30:11 UNRAID upsmon[26302]: UPS [email protected]: administratively OFF or asleep
Oct  8 17:30:11 UNRAID upsd[26295]: Client [email protected] set FSD on UPS [qnapups]
Oct  8 17:30:11 UNRAID upsmon[26302]: Executing automatic power-fail shutdown
Oct  8 17:30:11 UNRAID upsmon[26302]: Auto logout and shutdown proceeding
Oct  8 17:30:16 UNRAID shutdown[27242]: shutting down for system halt
Oct  8 17:30:16 UNRAID init: Switching to runlevel: 0
Oct  8 17:30:16 UNRAID flash_backup: stop watching for file changes
Oct  8 17:30:16 UNRAID init: Trying to re-exec init

 

Edited October 8, 2023 by ABEIDO

[Rysz]

1 hour ago, ABEIDO said:

 

I didnt know that with slave and master users, good info. Have changed that now.

 

The manual test acts the same as the schedueled in regards of symptons which i didnt thought was the case, so i have a way of testing solutions now. Btw i tested without Qnap running, didnt want to messup the NAS. And problems is the same even the load now only is 34w when ups is off.

 

Test 1

-Did a test before but with only Kill UPS Power change to No.

Only Unraid shuts down (correctly thou as it always had) but it does it directly. So not staying on until set rule.

 

Test 2

-Tested with all the suggested changes. Unraid shuts down (correctly thou as it always had) So not staying on until set rule. So same as before.

 

Test 3

-Tested with all the suggested changes but with Shutdown Mode Battery Level . Unraid shuts down (correctly thou as it always had). So not staying on until set rule. So same as before.

 

Saw below just before it turned off both times.

1

 

2

 

In Home Assistant (just as extra info). Yellow status name is same status as above 2. Black part is when unraid is off.

 

 

So still same issue but without the powerloss for the connected devices. When i thinkm about it i couldnt have had these problem before on the old repo. I mean i would remember that my nas/unraid/server was down randomly every 2 weeks as i cannot disable auto selftest (what i have found)

 

Only other ui option i havent touched is:

and

 

Are those of any importance in regads to the problem?

 

 

Some Log from a test.

 

 

 

So I've been able to reproduce the problem on my test server at last, thanks for your patience and testing. The culript is that the UPS seems to send an "OFF" event during the self-testing, which basically says "Hey, I'm offline and no longer providing power to your server" and NUT acts on that and starts a shutdown sequence because it requires at least one functional, online UPS.

 

This is the line where this happens:

Oct  8 17:30:11 UNRAID upsmon[26302]: UPS [email protected]: administratively OFF or asleep

 

What's even stranger is the UPS seems to be "OL" (Online) and "OFF" (Offline) at the same time, these two events shouldn't be able to exist at the same time. I'm guessing this is an APC driver issue with NUT and your specific UPS model or series, so I'll have to run this up to the NUT backend developers, the UNRAID plugin is basically just a frontend for the NUT backend (which is developed for more systems than UNRAID). What is curious is that I've found no report from other APC users where this happens, which makes me wonder if this is something that is just happening on your UPS or UPS series.

 

What you can try in the meantime:
Change the NUT backend to "legacy (2.7.4)" in NUT Settings -> Reboot -> Test

Change the NUT backend to "stable (2.8.0)" in NUT Settings -> Reboot -> Test

And please report back if the problem also happens on the different backends.

 

If it doesn't work with the other backends, I might have one more idea you could try.

It's not an ideal one, so I'll keep this as a last "solution" in case all else fails for now.

 

Please also let me know the exact UPS vendor and model that you have!

 

Edited October 8, 2023 by Rysz