Mat W

Well, I think updating unraid-api has resolved my issue. After the update it wrote INFO level logs into stdout.log and hasn't written anything more to stdout.log.1. I'll continue to monitor but I believe that "fixed" it. root@Unplucky:/var/log/unraid-api# ls -alh total 37M drw-r--r-- 2 root root 100 Jan 11 04:40 ./ drwxr-xr-x 13 root root 780 Jan 12 08:11 ../ -rw------- 1 root root 146 Jan 3 12:40 stderr.log -rw------- 1 root root 2.8K Jan 12 08:11 stdout.log -rw------- 1 root root 37M Jan 12 08:11 stdout.log.1

I'm looking at a similar situation with stdout.log.1 not-so-slowly filling up /var/log. It seems to be set to DEBUG level logging and is not rotating despite being >10MB in size. root@Unplucky:/var/log# ls -alh unraid-api/ total 37M drw-r--r-- 2 root root 100 Jan 11 04:40 ./ drwxr-xr-x 13 root root 780 Jan 11 03:00 ../ -rw------- 1 root root 146 Jan 3 12:40 stderr.log -rw------- 1 root root 0 Jan 11 04:40 stdout.log -rw------- 1 root root 37M Jan 12 08:05 stdout.log.1 Also interesting that it's writing to ".1" and not the standard named file.

Unfortunately, my current parity check finished 10 minutes before the nightly appdata backup started. I don't know if it would have resumed properly.

Update successful. Hopefully I've got enough parity check remaining to naturally make it passed the backup tomorrow morning. I'll let you know how it does.

Awesome! Glad to help.

Here you go. unplucky-diagnostics-20230906-1005.zip

The backups finished around 4:14am and the plugin registered they finished and it was outside of increment window at 4:18am. Sep 5 04:14:05 Unplucky kernel: br-fa8d007e8d97: port 2(vethb97540b) entered blocking state Sep 5 04:14:05 Unplucky kernel: br-fa8d007e8d97: port 2(vethb97540b) entered forwarding state Sep 5 04:18:21 Unplucky Parity Check Tuning: Send notification: backup no longer running: Sep 5 04:18:21 Unplucky Parity Check Tuning: Send notification: Array operation not resumed - outside increment window: Scheduled Non-Correcting Parity-Check (68.2% completed) I have enabled testing mode logging and will provide the diags tomorrow morning.

It failed to restart after the 4am backups again this morning. I'm seeing the "Array operation not resumed - outside increment window" messaging in the logs. I'm currently using the 2023.09.03 version of the plugin.

Will do, appreciate the quick reply.

Well then, praise be onto you. 🙂

I, too, am running into the multi-notification issue but just updated to the latest so I'd expect that to resolve. I do however have another behavior that is plaguing me. I've got my parity check scheduled from 12:30am - 7:30am with it pausing for updates, backups and mover which occur at 3am, 4am and 6am respectively. What I can't figure out is the parity check pauses at 4am and does not resume until the next day at 12:30am. This feels like a config issue and maybe not a bug. Anyone have any ideas? I can provide the diagnostics if it would help.

@scolcipitato thank you, thank you and thank you. I didn't realize how much I relied on the old Docker Folder plugin until the support for it died off. Then you came along! Any way to "buy you a cup of coffee"?

@FlamongOle - I can verify that my dashboard (and Disk Location settings tab) now work when disks are spun down!! Thank you for all your hard work. As promised, beer money sent.

It's a known issue at this point. If any of the drives are spun down, the dashboard and Disk Location device page will both be blank. If you spin up all drives, they should re-appear. At least that's how it is for myself and 1 or 2 others on this thread.

I should add that my Disk Location settings page goes blank when the dashboard is blank, similar to @SShadow.

Forgot to mention leaving the dashboard up for 5 minutes. I have the dashboard open in a tab at all times in Firefox. I haven't observed any issues with performance.

I am seeing the following in the php log when I brought up the dashboard prior to spinning up all drives. It's the same stack trace every time with nothing else in the log. [08-Jul-2023 07:34:26 America/Denver] PHP Fatal error: Uncaught TypeError: round(): Argument #1 ($num) must be of type int|float, string given in /usr/local/emhttp/plugins/disklocation/pages/devices.php:305 Stack trace: #0 /usr/local/emhttp/plugins/disklocation/pages/devices.php(305): round('*') #1 /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(706) : eval()'d code(25): require_once('/usr/local/emht...') #2 /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(706): eval() #3 /usr/local/emhttp/plugins/dynamix/template.php(82): require_once('/usr/local/emht...') #4 {main} thrown in /usr/local/emhttp/plugins/disklocation/pages/devices.php on line 305 I have no issue with supplying a diagnostic file if it will help?

I pulled down the C version just in case it worked. No change. I haven't come across any other pages or plugins having issues throughout this process. Again, really appreciate all the effort. Will definitely be "buying you some beer" when this is done!

@FlamongOle - Updated and still nothing on the Dashboard. I repeated the same testing steps as I did before, with the same results. Once the drives are spun up, the dashboard re-appears.

Awesome job on getting this out! Just did the update and, sadly, did not resolve the issue for me. I did the following steps to test... Logged out and back in Verified drives were spun down (all data and parity in fact) Tested in a private window to rule out browser plugins and cookies/cache Lastly, spun up the drives to see if dashboard appears... it did. Let me know what info you need from me to assist further.

I have discovered the offending plugin after combing through most of the plugin threads. There is an issue with the Disk Location plugin that caused the Dashboard to go blank BUT only when 1 or more drives is spun down. Spinning up all drives resolves the issue. This explains why everything would being working and then a drive would spin down and poof! I was going crazy, well, more so than usual.

You have no idea how happy I am to come across your comment!! I have been playing wack-a-mole with plugins for a couple of days now trying to figure out which one was causing the issue. <spins up all drive> Poof! The dashboard reappears. Let me know if you need any info from another system having the issue.

I'll 2nd that!!! Only wish there was a way to disable individual plugins rather than removing them, but I'll take preventing reboots.

Well, the Dashboard disappeared again. Is there a way to "disable" individual plugins to help troubleshoot which one is causing the issue?

So, I decided to put on my big boy pants and try the upgrade again. I did remove the Docker Patch plugin prior to the upgrade this time but otherwise it was the same process. Oh, and I did run the Upgrade Assistant beforehand which showed no conflicts. The upgrade went smoothly, just like last time and so far no issues with a blank dashboard. I guess I'll wait and see what happens.