Rysz

No, that's just the editor's syntax highlighting which is different in light and dark modes respectively.

Sorry this is outside of the scope of NUT (and UPS software in general). All NUT does is invoke the operating system's shutdown command when the respective shutdown conditions are met. How the OS chooses the handle the shutdown procedure itself is up to the operating system. In any case, one should always dimension the UPS to be able to sustain the target system at least under maximum load, if it cannot sustain the system under maximum load then it will likely also not provide much "on battery" time under regular load - which is a problem in itself. The solution you are asking for is a band-aid for the problem of a too small UPS for a too large system and not something that I want to add as it masks that actual problem - it would be better to purchase a sufficiently dimensioned UPS.

I can compile you a test package, what version of Unraid are you on?

Ich habe kürzlich ein System von 6.8.3 auf 6.12.10 aktualisiert, ohne irgendwelche Probleme. Habe vorher ein Flash Backup gemacht, fast alle Plugins deinstalliert und dann die Aktualisierung durchgeführt. Musste dann nur noch von "macvlan" auf "ipvlan" umstellen, was automatisch eingestellt war oder durch das Update wurde.

apcupsd (the in-built program) is just a different program with different drivers, it works well for some UPS and not so well for others. I'm glad everything works for you now with NUT, make sure you disable the in-built "UPS Settings" when using NUT so the two programs don't interfere with each other. 🙂

Not all UPS support this and it also depends on the implementation in the UPS driver itself. If it does not work for you with the in-built "UPS Settings" (apcupsd), you can also try with the NUT plugin.

I'm very sorry, I really have zero clue why this doesn't work for you. It works for me on my testing server and also for many other users who use these filters. 😕

That's really odd, did you enable the "Rule-based Syslog Filters" in NUT Settings and restart NUT? If you did, please try restarting NUT again and also run this command if that still doesn't work: /etc/rc.d/rc.rsyslogd restart

Can you guys chill out a bit please, after all everyone's entitled to their own opinion in this topic. Nobody's forcing anyone to use our plugin "crap" either, so feel free to use whatever works best for you.

TLDR (Command-Line Cheatsheets) for UNRAID "Oh man, how did that terminal command work again?" If you ever asked yourself that question, do continue reading! For space preservation reasons, Unraid OS does not come with the man command. The respective binaries' --help argument or looking online is how to reconstruct a forgotten command. Wouldn't it be nice to have a simple to understand, quick overview of the most common use cases? Wouldn't it be even nicer to have that right inside the terminal and not buried in an online forum somewhere? The TLDR pages are a community effort to simplify the beloved man pages with practical examples. Install once, easy to keep up to date and always at your instant disposal from the terminal. Programs get updated and commands can change, so updating the help definitions (or not) is a breeze. Project Page: https://tldr.sh (with Demo) / Source Code: https://github.com/tldr-pages/tlrc/tree/v1.9.2 As featured and further explained here: https://www.redhat.com/sysadmin/tldr-linux Installable via Community Applications

Change your xnut-nospam.conf via GUI configuration editor (in NUT Settings) so it looks like this: # # DO NOT CHANGE THIS FILE IF YOU DO NOT KNOW WHAT YOU ARE DOING # CHANGING THIS FILE CAN BREAK YOUR ENTIRE SYSTEM LOGGING CAPABILITIES # MAKING IT ALMOST IMPOSSIBLE FOR OTHERS TO HELP YOU IN CASE OF PROBLEMS # # NUT Rule-Based Repetitive Message Filtering (SYSLOG Anti-Spam Module) # https://www.rsyslog.com/doc/configuration/filters.html # https://www.rsyslog.com/doc/configuration/actions.html # # When adding new rules, be as specific as possible and filter as little # as just possible in order not to discard important diagnostic information # from both the SYSLOG itself and any otherwise generated diagnostic packages # :msg, regex, "UPS.*data is no longer stale" -/var/log/nut-spam :msg, regex, "UPS.*Data stale" -/var/log/nut-spam :msg, regex, "Communications with UPS.*lost" -/var/log/nut-spam :msg, regex, "Communications with UPS.*established" -/var/log/nut-spam :msg, regex, "UPS.*data is no longer stale" stop :msg, regex, "UPS.*Data stale" stop :msg, regex, "Communications with UPS.*lost" stop :msg, regex, "Communications with UPS.*established" stop :msg, regex, "nut_libusb_get.*Error" -/var/log/nut-spam :msg, regex, "nut_libusb_get.*Error" stop :msg, regex, "nut_libusb_get.*error" -/var/log/nut-spam :msg, regex, "nut_libusb_get.*error" stop Then restart NUT and the spam lines in log should disappear, can you confirm?

Hast du auf "Anmelden" geklickt? Es passiert nichts? Keine Sanduhr, drehender Kreis o.ä.? Probiere es doch auch mal mit einem anderen Browser und mit geleertem Cache und Cookies...

Your UPS is not listed as compatible to NUT, however you can try "Auto Config" if that improves anything. Otherwise you can try opening a ticket here: https://github.com/networkupstools/nut/issues But I haven't found anyone on the internet who's used your UPS in combination with NUT so far.

Are you sure this is the command you want to run? https://linux.die.net/man/8/xfs_db xfs_db is not for defragmentation, but seems to be for XFS diagnostic information. Looking at this script, as an example, another command (xfs_fsr) seems to be used: Honestly I'd not bother with XFS defragmentation, especially if you're not that proficient with Linux command-line or filesystems. 99% of users do just fine without any defragmentation, and it'd be included in Unraid if it were necessary or even recommended. Also please reconsider randomly running force options like that in the future, that'll really mess things up if you're not 100% sure. Running random filesystem commands on all of your disks and forcing operations when things don't work will screw up something.

The whole one, otherwise I won't be able to help you...

Du hast wahrscheinlich noch gleichzeitig einen Trial-Key am USB. Du müsstest die Trial.key Datei aus dem "config"-Ordner am USB-Stick löschen & dann neu starten.

For what it's worth I've been and still am using a i3 9100 CPU with its iGPU and ECC RAM for the past 4 years. My server has had up to 300 days of uptime with zero crashes, problems or reboots on versions 6.8.3 to 6.12.11. I'm using Plex and transcode up to 4K often using the iGPU, the experience there has also been nothing but flawless. I haven't tried it on 7.0.0-beta.2 with that hardware just yet, to be fair. But I expect you're not the only person on the beta with a 9th generation CPU. Have you considered maybe doing a RAM test or selectively disabling some of your plugins/containers? I've seen some users where RAM problems caused such freezes, or a broken plugin or container as well. If you've been plagued by freezes and reboots for two years, this likely is not something introduced by the beta. Hardware or plugins/containers you've been using for that long might be worth looking into and reconstructing your steps.

There are no pre-crash logs, you'll have to set up SYSLOG server and wait if it happens again. Any recent changes you've made, new or changed hardware, plugins... ? Did this happen before?

Hello! The way I understood your question, ideally you would rebuild one of the 4TB disks onto the new 20TB disk: https://docs.unraid.net/legacy/FAQ/replacing-a-data-drive/ Then you'd shrink the array either doing a new configuration (rebuilding parity) or the more complicated shrink array procedure (preserving parity): https://docs.unraid.net/legacy/FAQ/shrink-array/ (shrinking the array meaning removing the obsolete 4TB drive) But honestly I'd keep the obsolete 4TB drive in the array and replace it with a larger drive down the road, as that doesn't expose you to the vulnerability of having to rebuild your parity (during which your other drives would not be protected) or having to follow the complicated shrink array procedure. For me personally the little amount of energy saved would not be worth that risk or effort, I'd just keep that disk spun down and replace it with a larger disk in the future. 🙂

Please post the NUT Debug Package that can be found in NUT Settings.

Thanks for your efforts, you will have to wait now until your changes are merged, usually done by @SpencerJ.

That being said, "Runtime Left" is the least reliable of the three shutdown modes. The runtime reported by the UPS and the actual possible battery runtime can fluctuate and vary a lot depending on both the battery health and the implementation of the calculation mechanism in the UPS. I generally recommend to use "Time on Battery" or "Battery Level" as more reliable mechanisms. My UPS - for example - are set to shutdown after 2 minutes on battery, as by that time usually a recovery of the mains power is no longer to be expected (if it doesn't recover within 2 minutes it's usually down for a lot longer than the UPS could cover).

Is there some type of JavaScript blocking enabled on the browser? Otherwise I'd try to clear the cache and cookies from the browser, see if that resolves it.

He also made this topic, I also don't think it's a good idea (personally):

I never claimed it's more performant than either, the point was that performance is not everything there is to the equation.