On 1/25/2026 at 5:37 PM, Gico said:

I had been running a parity sync for several days. I paused it, stopped the array, and then started it again.

The parity sync restarted from zero — why did that happen?

juno-diagnostics-20260125-1925.zip

Not sure. I can see that when you stopped the array that restart information was saved. However I see that something went wrong later as there is an indication that restart information was no longer present. I have some thoughts on what could cause this but I will need to do some testing to be see if my idea is a possibility.

On 9/26/2025 at 3:15 AM, BurningSky said:

The error has come back again, from the notifications panel:

Parity_Check_Tuning_1758855103.notify

26 Sept, 08:09
Parity_Check_Tuning_1758855103.notify

This notification is invalid and cannot be displayed! For details, see the logs and the notification file at /tmp/notifications/unread/Parity_Check_Tuning_1758855103.notify

And when I cat that message

~# cat /tmp/notifications/unread/Parity_Check_Tuning_1758855103.notify
timestamp=1758855103
event=Parity Check Tuning
subject=[RAGON] mover running
description=
importance=normal
link=/Settings/Scheduler

Looks like a blank description again so that might have been the cause. My change to the script to replace blank descriptions must have been overwritten

FYI, still seeing these notifications for the following events (so far) with nothing going on in the syslog around the same timestamps:

Hi,

Ok, my little test server runs this plugin since it's new version issued in January. I came accross a little bit annoying, uhm... bug? This is what happens 7-8 times out of 10:

• Server shut-down or restart initiated by using Shutdown/Restart buttons on Main page.

• Next system boot (it doesn't matter if it is after after a restart or a shutdown + 'cold boot') -> login -> and got an error notification immediatelly:

  Parity Check Tuning

  <date> <time>

  [<server_name>] Unclean shutdown detected

  System crashed

• ...and parity check starts automatically...

Ok, a side note: not everytime happens this. As I wrote above, my statistics is that it happens in 70-80% of the cases of reboots/shutdowns.

What do you need to analyze this? System log? Diagnostics? Diag. is not a problem, I can send it, but for the log files, I guess you need the log when the system is shutting down... AFAIK there is a settings somewhere to save the log to the flash automatically...

2 hours ago, DelDadam said:

Unclean shutdown detected

https://forums.unraid.net/topic/69868-dealing-with-unclean-shutdowns/

2 hours ago, DelDadam said:

save the log to the flash automatically...

Syslog Server

@trurl: Thank you for your reply. I checked out that topic about unclean shutdown...

In my case:

• no VMs (service is not running)

• Docker service enabled, but no Docker containers were running

• Tips & Tweaks plugin installed, to kill terminals (ssh + bash) is set

• Array: delay was set to default 60 secs, which is usually way more/longer than a normal stopping process of array needs (on this particular machine)

• The only remaining 'variable' is: I have no clue how long does Unraid need to shutdown plugins. I have 14 plugins installed, but obviously I have no info about which one of these requires how long a shutdown time.

The only disturbing fact is that this 'unclean shutdown detected' event does not happens every time. Only sometimes, while the config of the server not changed (mostly) during my test/check period.

Ok, I'll set-up a local syslog server, and watch for log entries next time...

8 hours ago, DelDadam said:

shutdown plugins

As far as I know this isn't a factor. Unclean shutdown is about whether or not the array has stopped. If you time how long it takes when you press the STOP button in ARRAY OPERATION, that should be enough. VMs and dockers can affect that so should be included in testing STOP.

Started/Stopped status is saved to flash when the status changes, and that is what it uses to determine if it was unclean when it boots next time. If for some reason that status can't be updated on flash when you stop, it will be considered unclean.

It is worth pointing out that the Unclean Shutdown notification from the parity check tuning plugin is just information from the plugin that Unraid has detected an unclean shutdown. The idea is to save you having to look through the syslog to find this out. It is Unraid (not the plugin) that automatically starts a parity check after an unclean shutdown.

Hello All,

Meanwhile I've figured out what was wrong. As I didn't experienced the unclean shutdown symptom every time, I started to check timings/delays. The problem was that array was set to spin down after 15 mins of inactivity. If I restarted the server while the disks were spun down, they had to spin up before the array could be stopped - and the value of delay before shutdown (for a graceful reboot) was too small in this case. However if the disks were spinning, the same delay value was OK. This was the reason for that I've seen the error in the log some times, but not every time. Changed the delay to 90 secs, since then no unclean shutdown error logged.

Thx. for the help.

Parity check doesn't appear to be resuming/stopping for me at the expected times that are set in the settings.
The scheduled check started at the correct time yesterday (1am); however, it paused briefly at the scheduled stop time of 11am, but then resumed 6 minutes later by itself.
I, updated the plugin, as I was on the previous version, I checked the settings, adjusted the pause time to 10:30 and then waited until today, the parity check did not resume until 11:30 (an hour after the scheduled stop time), and at time of me writing this post is still running.

I've tried to get a screenshot of both the settings page with the syslog from the server, and I've annotated it as best as I could with the actions I took.
Please let me know if I can provide anything else to help troubleshoot.

@pooley182 Not sure how the symptoms you describe could happen. Can you check the contents of /etc/cron.d/root as that should have entries for when the pause/resume will happen. Maybe that does not correspond to the settings you have set in the plugin's settings for some reason. That would indicate that for some reason the settings are not getting saved to the flash drive. You could also check that the /boot/config/plugins/parity.check.tuning/parity.check.tuning.cfg file seems to correspond to the settings you think you have set. There will also be a /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron file there that should have the same settings as in the plugin's entries in the /etc/cron.d/root file.

To be able to do a detailed analysis I would need a copy of the syslog with the 'testing' mode logging set in the plugins settings and the problem recreated.

Thanks for getting back to me, I've just checked each of those files you suggested, and everthing looks fine in terms of config.

Just a quick question, I realised I had mover set to run at 11:00 and increment pause time also at 11:00, with "Pause array operations while mover running" also set to "Yes".
Could that have caused my issue? with maybe the Pause array operations getting in first, pausing the parity check at 11:00 before the pause cron ran, and then restarting at 11:06 not knowing it should be in a paused state?

I run a partiy check every 3 months, so I'll set myself a reminder to turn on test logging and see if it occurs next time. I've been using the plugin for a while, and this is the first time I've ever had the issue, so hopefully it was just a one off.

On 2/1/2026 at 5:59 PM, sMACk said:

FYI, still seeing these notifications for the following events (so far) with nothing going on in the syslog around the same timestamps:

just wanted to say these have all stopped appearing and I am seeing valid notifications, so thank you for your work!

6 hours ago, pooley182 said:

Just a quick question, I realised I had mover set to run at 11:00 and increment pause time also at 11:00, with "Pause array operations while mover running" also set to "Yes".
Could that have caused my issue? with maybe the Pause array operations getting in first, pausing the parity check at 11:00 before the pause cron ran, and then restarting at 11:06 not knowing it should be in a paused state?

That is a possibility although in theory the code that resumes after mover finishes does try and work out if it should resume otnot. It could depend on the exact sequence at which things happened. Having said that I think that if you are running a manually initiated parity check it may not always work and assume you have taken control.

Just issued an update that resolves a number of small issues, particularly around the Parity Problems Assistant. Should be no obvious change in capabilities.

There is one annoying outstanding issue in that many of the strings in the plugins pages still display in English when a different display language is selected. It is not all clear why and I am wondering if the plugin is encountering some limitation within the Unraid multi-language support.

Any Problems with Unraid 7.3.x or Supporting this Versions?