Rysz

If you have time and could check one more thing, just to be 100% sure: When you disable runtimecal (just comment out with #) can you confirm that battery.runtime is no longer in variable table?

Thanks a lot for testing, I'll get the changes upstreamed so this will be fixed for future NUT versions. In the meantime you can use the older backend where this still worked or patch the file I gave you in manually.

I'm very sorry, I forgot you're on the older OS version - this one should work. nutdrv_qx

Thanks a lot, that would be great so we can get this fixed for all future versions also. 😉

@SimonF If you are still on the default (2.8.4) backend can you try this fixed up driver? Stop NUT, then put this file into /usr/libexec/nut (backup old one/overwrite) and chmod +x /usr/libexec/nut/nutdrv_qx. Then start NUT again and please see if the problem still occurs or if it works now... let me know, thank you. 😀 nutdrv_qx

Yeah, this is due to the driver issue part - I'm hoping we can get this fixed in the backend soon as well. P.S. Note that you can switch the NUT backend to "previous (2.8.3 stable)" for the previous version, which worked for you.

This should now be fixed in today's plugin update; I also opened an upstream bug report for the driver: https://github.com/networkupstools/nut/issues/3075

Can you check the PHP logs? I've never seen this before, it should only happen for a HTTP or PHP issue. Which OS version are you running?

Ah, I see what you mean now. A reinstall or reboot is only required if you change the NUT backend using that setting where it says that. I'm glad that you got it working again, regardless.

I'm not sure what you did, but the plugin doesn't tell you to reboot. Try to boot into safe mode, which will disable all plugins. If that doesn't work - it's not a plugin related issue. If that works - uninstall any plugins one by one to see which one causes the issue.

You can just delete the respective .plg file in /boot/config/plugins. It would be interesting to know what problem you're having exactly and where it gets stuck though, as this problem has never occured to any other users before.

Liebe User des deutschen Subforums, es gibt bereits seit einigen Jahren einen offiziellen Unraid Discord Server mit über 12.000 Mitgliedern: https://discord.unraid.net/ Dieser wurde eingerichtet, damit sich Interessierte über technische Themen austauschen und sich bei Problemen gegenseitig unterstützen können. Kürzlich haben wir den Server um einen deutschsprachigen Kanal erweitert, also schaut doch gerne einmal bei uns vorbei - wir freuen uns auf euch! 🙂 Euer Team des Unraid Discord Servers

I identified a couple of potential edge-case issues in the shutdown logic, which should be resolved in the latest update. A lot of the shutdown script was mostly unchanged legacy code, I've refactored and modernised it with additional safeguards.

It does look like everything worked, as far as the shutdown sequence is concerned. Does your system have little CPU or maybe it was under extreme resource pressure when this happened? Because it's weird it took more than a minute longer to start shutdown (6m) and then another full minute to set FSD (7m). If you had even more delay after FSD (after the last log line) maybe the array took long to stop due to running services (resource pressure)?

Nothing was changed with the shutdown logic in the plugin, is there anything in the logs?

This is now fixed with the next update and you should see its effects after that (so the update after the next update). The reason you won't see it with this (next) update is because the rc.d script needs to update with the new changes first. Here's how I addressed this in the end, if you're curious: https://github.com/desertwitch/NUT-unRAID/commit/ef2f38f

Thanks for the report, I found some problematic code that could cause this behaviour with some browsers. Please let me know if that issue is resolved for you after updating to the latest version (which I've just pushed).

It is, if you open the window from the toolbar: or using the pop-up button when accessing from the TTM Settings page:

Did you try clearing cache or from another browser, seems like the rest of the page gets cut off somehow - CTRL+F5 can help force a refresh.

Which version of the OS are you on? Please post your diagnostics file as part of your next reply to this topic.

The base distribution and its packages are updated as part of the regular Unraid OS updating process, nothing the user needs to take extra care of there.

Thanks for pointing this out — your observations are correct. The rc.d script is fairly old and generic, so the stop command attempts to stop everything it knows about. As a result, it tries to shut down all parts of the NUT ecosystem, even though in a slave mode setup there will never be any upsd or driver instances running. This leads to misleading “failure” messages when it attempts to stop processes that were never started. I’ll adjust this in upcoming updates to suppress these unnecessary warnings in such cases, while still attempting to stop everything to account for broken configuration states.

Split from: https://forums.unraid.net/topic/192855-unraid-crashing-and-cannot-see-anything-obvious-in-the-logs

You need to put the changes on line 8 or later, they will persist if you follow the guide to the point. Also you need to use the NUT Configuration Editor in NUT Settings (Web GUI) otherwise it won't work.

It's a known firmware issue with that series, please check this post for how to fix it: