Rysz

Did you run into the bogus status issues before or this is the first time using NUT with this new UPS?

I don't think it worked, it was probably just luck that there were not more events. Thanks for trying again with the additional configuration line and also UPS Driver Debug Level on Level 3 (do make sure it is UPS Driver Debug Level that is set to Level 3 and not NUT Monitor Debug Level). Thanks very much again for your help with trying to pinpoint the issue. 🙂

Thanks - "UPS Driver Debug Level" 3 should be enough, otherwise the log file may become too big for Unraid if you let it run many hours. Also, before you do, can you please try adding this line to your UPS.CONF (at the bottom, so it's not overwritten) and then let NUT run with UPS driver debug level 3 for a few hours and collect the logs? lbrb_log_delay_sec = 3 Then please post the NUT debug package again (that includes all the important information for us). 🙂

Still thanks a lot for reporting back, this is valuable information that'll hopefully help us resolve these problems. 🙂

Being on battery power should not affect the USB devices. What I mean is you should try with the existing USB cable (between Unraid and the UPS) on another USB port (of your Unraid server). If that doesn't work maybe you have another USB cable around that you can try instead of the current one.

It seems your USB device keeps dropping offline every few seconds, do you use some power saving utilities perhaps? Did you make any other changes to your system recently? Have you tried on another USB port or with another USB cable?

I doubt CA is going anywhere, but even if that were the case it's always possible to install plugins via direct URL (as it was before CA existed). I could personally picture a screen with popular plugins being suggested to the user for installation (as part of the initial OS setup), but I wouldn't like to see anything come pre-installed personally.

Getting these quite often recently when searching for something in CA on Unraid 6.12.11. Appears seemingly random and no search results at all are displayed when the error occurs. Sometimes the error would appear 10 times in a row, then it'll work once (with the same search term). However it does not seem related to the search term itself, it will happen with any random search term... Something really wrong went on during get_content Post the ENTIRE contents of this message in the Community Applications Support Thread https://forums.unraid.net/topic/38582-plug-in-community-applications/ OS: 6.12.11 Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0 Language: <br /> <b>Warning</b>: Undefined array key "Featured" in <b>/usr/local/emhttp/plugins/community.applications/include/exec.php</b> on line <b>929</b><br /> <br /> <b>Warning</b>: Undefined array key "Featured" in <b>/usr/local/emhttp/plugins/community.applications/include/exec.php</b> on line <b>929</b><br /> <br /> <b>Warning</b>: Undefined array key "Featured" in <b>/usr/local/emhttp/plugins/community.applications/include/exec.php</b> on line <b>929</b><br /> {"display":"<div class='ca_templatesDisplay'><script>addDockerWarning(false);var dockerNotEnabled = false;<\/script><script>showSidebarApp('\/tmp\/community.applications\/tempFiles\/templates-community-apps\/CorneliousJDsRepository\/acaranta-JoplinApp-latest.xml','JoplinApp');<\/script><script>changeMax(24);<\/script> <div class='ca_holder spotlightHome ca_appPopup ' data-apppath='\/tmp\/community.applications\/tempFiles\/templates-community-apps\/CorneliousJDsRepository\/acaranta-JoplinApp-latest.xml' data-appname='JoplinApp' data-repository='CorneliousJD&#039;s Repository' > <div class='ca_bottomLine ca_bottomLineSpotLight'> <div class='infoButton ca_appPopup'>Info<\/div> <div class='supportButton supportButtonCardContext' id='supportJoplinApp753' data-context='[{\"icon\":\"ca_fa-project\",\"link\":\"https:\\\/\\\/github.com\\\/acaranta\\\/docker-joplin\",\"text\":\"Project\"},{\"icon\":\"ca_fa-support\",\"link\":\"https:\\\/\\\/forums.unraid.net\\\/topic\\\/103022-support-joplinapp-corneliousjd-repo\\\/\",\"text\":\"Support Forum\"},{\"icon\":\"docker\",\"link\":\"https:\\\/\\\/hub.docker.com\\\/r\\\/acaranta\\\/docker-joplin\\\/\",\"text\":\"Registry\"}]'>Support<\/div> <div class='actionsButton' data-pluginURL='' data-languagePack='' onclick=popupInstallXML('\/tmp\/community.applications\/tempFiles\/templates-community-apps\/CorneliousJDsRepository\/acaranta-JoplinApp-latest.xml','default','','[\"5800\",\"41184\"]');>Install<\/div><span class='appDocker' title='This application is a docker container'><\/span><span class='favCardBackground' data-repository='CorneliousJDs Repository' style='display:none;'><\/span><span class='pinnedCard' title='This application is pinned for later viewing' data-pindata='acaranta\/docker-joplinJoplinApp' style='display:none;'><\/span><\/div><div class='ca_appPopup ca_backgroundClickable'><div class='ca_iconArea'> <img class='ca_displayIcon ' src='https:\/\/raw.githubusercontent.com\/CorneliousJD\/Docker-Templates\/master\/icons\/joplin.png' alt='Application Icon'><\/img> <\/div> <div class='ca_applicationName'>JoplinApp <\/div> <div class='ca_author'>CorneliousJD&apos;s Repository<\/div> <div class='cardCategory'>Productivity<\/div> <\/div> <div class='cardDescription ca_backgroundClickable'><div class='cardDesc'>This container allows you to have a working Joplin desktop app, reachable via a http noVNC that can be placed behind a reverse proxy. Can also be used with the Joplin server container to have a full Joplin stack on unRAID! More info about Joplin : https:\/\/joplinapp.org\/ <\/div><\/div><\/div><script>data.currentpage = 1;<\/script><\/div>"} PHP Error Log: PHP Warning: Undefined array key "Featured" in /usr/local/emhttp/plugins/community.applications/include/exec.php on line 929 PHP Warning: Undefined array key "Featured" in /usr/local/emhttp/plugins/community.applications/include/exec.php on line 929 PHP Warning: Undefined array key "Featured" in /usr/local/emhttp/plugins/community.applications/include/exec.php on line 929 P.S. It also happens in Chrome... and CA is up to date.

While differing opinions, negative feedback and criticism are OK, please try to remain respectful towards others while expressing it. 🙂

That being said, aside from stability, more importantly not everyone needs every functionality and plugins are a good way to keep the OS debloated while letting the users choose what they want or need themselves. 🙂

Go to Settings => SMB There you can put an additional share configuration into "Samba extra configuration", e.g.: [mergerfs] path = /mnt/addons/mergerfs comment = browseable = yes # Private writeable = no read list = write list = yourUserNameHere valid users = yourUserNameHere case sensitive = auto preserve case = yes short preserve case = yes vfs objects = catia fruit streams_xattr fruit:encoding = native Make sure to change yourUserNameHere to the username of the user you want to give access to. After that you should be able to access your custom share using Samba (SMB) and see your mergerFS files.

The Unassigned Devices plugin creates 1MB tmpfs RAM-disks for the /mnt subfolders: disks, remotes, addons and rootshare. This 1MB is enough to create the mountpoint folders, but if a mountpoint drops offline (e.g. due to a network outage) it also ensures a Docker cannot write more than 1MB to that location, which is now no longer in the network but on the RAM-disk (because the mountpoint dropped offline). /mnt/addons has become the standard location on Unraid where to put custom mounts and have the protection against such unwanted writes in case the mountpoint drops offline for whatever reason. You can see this if you run the command "df -h", as an example: tmpfs 1.0M 0 1.0M 0% /mnt/disks tmpfs 1.0M 0 1.0M 0% /mnt/remotes tmpfs 1.0M 0 1.0M 0% /mnt/addons tmpfs 1.0M 0 1.0M 0% /mnt/rootshare So it is best practice to put any custom mountpoints into /mnt/addons, e.g. /mnt/addons/mergerfs. Ideally you will use the array_start_complete.sh of mergerFS, so that the Unassigned Devices plugin is finished setting everything else up before mergerFS starts the mounting process. Here is an example array_start_complete.sh script with fictitious folder names: mkdir -p /mnt/addons/mergerfs sleep 1 mergerfs /mnt/remotes/A:/mnt/remotes/B:/mnt/disk1 /mnt/addons/mergerfs

Unraid is stored in RAM so any changes to the filesystem, like creating a mountpoint folder, are lost on reboot. You can solve this by creating the mountpoint folder right before the actual mergerfs command in the same plugin's .sh scripts - here's an example: mkdir -p /mnt/addons/mergerfs sleep 1 <your mergerFS mount command here> But I would strongly advise to put the mountpoint folder in e.g. /mnt/addons/mergerfs as that is better protected against overflowing writes in case of network outages. If the network connection drops and your mountpoint folder is in /mnt/mergerfs instead of /mnt/addons/mergerfs, the Docker containers could continue to write to that unprotected location, eventually filling up all the rootfs ( / ) and bringing down the server. /mnt/addons/ is protected against such overflows by being located on a separate RAM-disk (and not the rootfs / ), so your Docker containers would just stop writing once that RAM-disk limit is violated. Please let me know if that worked out for you!

This is merely a diagnostic message from the "Live Memory Tester" plugin that checks for a running process of itself before installing. It doesn't mean anything is wrong and it shouldn't appear in the system logs, merely on the boot screen (as that's extremely verbose by default).

Not to hijack this thread, but if you need graphical statistics urgently you can also use the DVM (Data Volume Monitor) plugin until this plugin is updated respectively, which is also using vnStat.

These seem like I/O errors rather than corruption, which is also why you are not getting scrub errors either. Is the NVME connected directly to the motherboard slot or through some cheap-ish NVME controllers perhaps? Did you make any changes to the system prior to this happening for the first time?

Post diagnostics please.

I'd use bond0 as default interface, eth0 is kind of legacy and bond0 should be a better default.

There is an obvious problem with the UPS before drive spin-ups even occur. Before spinning up the drives, the UPS is already forcing an emergency shutdown because it sees the battery charge is critically low. This can happen if you let the system run on battery for too long and then it's obvious it won't be able to handle the load of the collective spin-up anymore either, with the battery charge already being that depleted. Even worse if NUT really instantly does this when the power goes out, as you say it does, then this is a serious issue with your battery being completely degraded or otherwise wrong for the task (too small battery, wrong battery type such as a car battery hooked up to a UPS, ...). Please read the various explanations by me and other people on this topic once again. I don't know how to put it much clearer than this: Please stop asking for it, it's not happening. I don't know what UPS you are using but it's obviously the wrong choice for the task you require, once more - you need a UPS that can sustain what you are calling the "SURGE" load. A mediocre software solution to a hardware choice issue is not something that is within the scope of the plugin or that will be implemented. Sorry for the blunt answer, but I really don't know what else there is to say here.

nut-2.8.2-x86_64-2eapr.txz 1) Stop NUT in NUT Settings 2) Run this command (if you still have the testing package installed): removepkg nut-2.8.2-x86_64-1eapr.txz or (if you don't have the testing package installed anymore): removepkg nut-2.8.2-x86_64-1stable.ssl11.txz 3) Put the testing file onto the system somewhere 4) Run this command in the folder where you put the testing file: installpkg nut-2.8.2-x86_64-2eapr.txz 5) Start NUT in NUT Settings 6) Confirm backend now shows as "nut-2.8.2-x86_64-2eapr" in NUT Settings

On another note, just because I won't add this to NUT, doesn't mean you can't do it with NUT yourself. You can always modify the SHUTDOWNCMD or better NOTIFYCMD to point to a custom script that does this. https://networkupstools.org/docs/man/ups.conf.html

Here is the pull request #2562 compiled into a package: nut-2.8.2-x86_64-1eapr.txz 1) Stop NUT in NUT Settings 2) Run this command: removepkg nut-2.8.2-x86_64-1stable.ssl11.txz 3) Put the testing file onto the system somewhere 4) Run this command in the folder where you put the testing file: installpkg nut-2.8.2-x86_64-1eapr.txz 5) Start NUT in NUT Settings 6) Confirm backend now shows as "nut-2.8.2-x86_64-1eapr" in NUT Settings

Sorry I didn't forget about you, I'm just not near the computer I'm compiling on at the moment. I'll try to compile you a package or provide you the configuration file this afternoon hopefully, sorry for the wait.

I understand what you are saying: Your UPS is not able to sustain the peak load of all drives spinning up, but is able to sustain the load of all drives already spinning. But this is exactly the problem I was talking about, the maximum load you need to scale your UPS for is the actual maximum load that is theoretically possible on the target system and not anything below that. Let's take the example you have given: If you must spin down your disks, you need a UPS to support 1215W and not 197W, even if it only reaches the 1215W during spin-ups. You simply cannot rely on your drives not spinning up all at once randomly and for whatever reason during battery operation. Even if I were to implement the feature you are asking for, your UPS would still crash if literally anything else caused a spin-up of all disks while it is on battery power - there's just no point to only implement this in NUT. If you really want that, you better ask for a OS feature that allows staggered spin-ups if anything causes a spin-up of all disks during runtime, and not just NUT shutting down the server (which is in fact the OS shutting down the server, as NUT just sends the regular shutdown command). No offence, you need a UPS that can support what you are calling a "surge" but is actually just the maximum load that you should have scaled your UPS for. You are running 12 disks and you are already running into this problem, how do you think some of the users with up to 60 disks are using their UPS and NUT without this feature you're asking for? This literally is the first time I'm hearing about this problem. P.S.: A staggered spin-up only makes sense like that (as in the video above) if you set it up in your BIOS or HBA BIOS and keep the drives always spinning afterwards. Then you'd theoretically be able to run with a smaller UPS, but it's still bad practice in my opinion. This should only be for cases where the PSUs are not able to support the peak load of all drives spinning up at boot time and then keep spinning afterwards, as spin-ups are just not a well controllable situation within the OS (unless the drives are always spinning).

Sorry but this still makes no sense to me. You say that your UPS is dimensioned large enough to sustain 20 minutes of your server's maximum load and only lose 50% of its battery charge in the process. If it's able to hold the server's maximum load for 20 minutes, that is likely nowhere near the UPS rated maximum load... otherwise the UPS wouldn't be able to hold it for that long (20 minutes is a very long time in a high utilization scenario). So if the UPS is in fact dimensioned large enough to be able to hold the server's maximum load for 20 minutes and still have 50% battery charge remaining, it certainly shouldn't care for the increase from the server's regular load to the server's maximum load even if within a short time-frame. If it does care about that spike from e.g. 20% utilization to e.g. 50% utilization then this is a hardware issue of the UPS. Such a feature would be a band-aid to cloak a UPS hardware issue at best, and not a good one at that, so I'm not going to add this to the plugin with it doing more damage than good. As others have pointed out, such a problem is not limited to shutdowns... a full disk spin-up can occur at any time (parity check, containers scanning files, search indexing, ...) and you can't plan for that. There's no point in having a UPS if it crashes your system anytime a full disk spin-up occurs in an on battery situation, which might well happen before the shutdown (especially if you have your UPS running for 20 minutes). A staggered spin-up at shutdown won't prevent anything else causing a spin-up.