[Plugin] Parity Check Tuning

[DontWorryScro]

On 7/9/2022 at 9:00 AM, b0m541 said:

Oh ok, I did not have the big picture that there are actually two settings in different places that are interrelated:

 

Parity Check Tuning: Pause array operations while mover is running

Mover Tuning: Let scheduled mover run during a parity check / rebuild

 

I will set them as follows because I want mover to run daily, but not have a running Parity Check at the same time:

 

Parity Check Tuning: Pause array operations while mover is running: Yes

Mover Tuning: Let scheduled mover run during a parity check / rebuild: Yes

 

Correct?

 

I am happy that this is clear to me now. To help others to avoid this confusion maybe the help texts of both Tuning plugins for the above mentioned options could be amended to point out that there is an interrelated option in the other tuning plugin and what combinations lead to what result.

 

Thanks for the clarification.

 

 

 

 

oddly i have mine set this way but for whatever reason it's not working properly.  I feel like there's some cron job running somewhere that is interrupting how this is supposed to work for me.  I have both those options you mentioned set to Yes but what happens for me is the Parity-Sync will indeed pause when mover starts running nightly at 1:40am.  Then in the morning i return to see that the Parity-Sync never resumed.  I'll check the logs to see that the mover did indeed finish a while ago.  So why did the Parity-Sync not resume?  At this point I can either wait for the random notification to pop up mid day that mover has finished and parity sync is resuming (even though I know mover to have finished hours previously) or I manually resume.

 

Maybe if I paste my settings someone can tell me where I brain farted? 

 

snuts-diagnostics-20230629-1425.zip

Edited June 29, 2023 by DontWorryScro
Adding Diagnostics

[robobub]

  

On 6/29/2023 at 1:35 PM, DontWorryScro said:

oddly i have mine set this way but for whatever reason it's not working properly.  I feel like there's some cron job running somewhere that is interrupting how this is supposed to work for me.  I have both those options you mentioned set to Yes but what happens for me is the Parity-Sync will indeed pause when mover starts running nightly at 1:40am.  Then in the morning i return to see that the Parity-Sync never resumed.  I'll check the logs to see that the mover did indeed finish a while ago.  So why did the Parity-Sync not resume?  At this point I can either wait for the random notification to pop up mid day that mover has finished and parity sync is resuming (even though I know mover to have finished hours previously) or I manually resume.

 

I think you just encountered the issue I did with temperature pause/resume. From the comments, it looks like the logic also applies to pause/resume from mover action. I made a pull request here.

 

Making these changes in /usr/local/bin/parity.check seem to be working for my case, though I did not check the second case yet. TESTING logs before the change for context

 

Quote

Jul  2 01:54:46 t1001 Parity Check Tuning: TESTING:MONITOR Heat notification message: Pause: Following drives overheated: disk2(47C) 
Jul  2 01:54:46 t1001 Parity Check Tuning: Pause
Jul  2 01:54:46 t1001 Parity Check Tuning: Following drives overheated: disk2(47C) 
Jul  2 01:54:46 t1001 Parity Check Tuning: TESTING:MONITOR ----------- MONITOR end ------
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING: ... appears to be manual parity check
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING: triggerType: MANUAL
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING: actionDescription(check P, 0, Manual, 1) = Manual Non-Correcting Parity-Check
Jul  2 02:00:45 t1001 Parity Check Tuning: DEBUG:   Manual Non-Correcting Parity-Check paused
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR ----------- MONITOR begin ------
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR /boot/config/forcesync marker file present
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR progress marker file present
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR manual marker file present
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR disks marker file present
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR hot marker file present
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR isArrayOperationActive - parityTuningActive:1, parityTuningPos:2400631784
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR ... appears to be manual parity check
Jul  2 02:00:45 t1001 Parity Check Tuning: Manual Non-Correcting Parity-Check: Manually paused
Jul  2 02:00:45 t1001 Parity Check Tuning: TESTING:MONITOR PAUSE (MANUAL) record to be written
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR written PAUSE (MANUAL) record to  progress marker file 
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR ... appears to be manual parity check
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR triggerType: MANUAL
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR actionDescription(check P, 0, Manual, 1) = Manual Non-Correcting Parity-Check
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR paused marker file  created to indicate how Manual Non-Correcting Parity-Check was started
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR backGroundTaskHandling: configName=parityTuningMover, value=1, isMoverRunning=0, Array: Active=1, Paused=1
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR backGroundTaskHandling: configName=parityTuningBackup, value=1, isBackupRunning=0, Array: Active=1, Paused=1
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR global temperature limits: Warning: 50, Critical: 55
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR plugin temperature settings: Pause 3, Resume 4, Shutdown 0)
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR parity temp=45C, status=cool (drive settings: hot=47C, cool=46C, critical=55C)
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR disk1 temp=43C, status=cool (drive settings: hot=47C, cool=46C, critical=55C)
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR disk2 temp=46C, status=cool (drive settings: hot=47C, cool=46C, critical=55C)
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR disk3 temp=44C, status=cool (drive settings: hot=47C, cool=46C, critical=55C)
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR disk4 temp=43C, status=cool (drive settings: hot=47C, cool=46C, critical=55C)
Jul  2 02:00:46 t1001 Parity Check Tuning: DEBUG:   No drives appear to have reached shutdown threshold
Jul  2 02:00:46 t1001 Parity Check Tuning: DEBUG:   array drives=5, hot=0, warm=0, cool=5, spundown=0, idle=0
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR Some drives spun down - assume they are cool
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR pos= parityTuningPos, size=13672382412,  (17.6% completed)
Jul  2 02:00:46 t1001 Parity Check Tuning: Resumed Manual Non-Correcting Parity-Check  (17.6% completed) Drives cooled down
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR Heat notification message: Resume: Drives cooled down
Jul  2 02:00:46 t1001 Parity Check Tuning: Resume
Jul  2 02:00:46 t1001 Parity Check Tuning: Drives cooled down
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR Deleted hot marker file 
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR Check if within increment active period
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR ... Active=1, Action=check P, Restart=
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR .. PauseTIme=660, Resumetime=0, currentTime=120
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR isAcivePeriod()=0
Jul  2 02:00:46 t1001 Parity Check Tuning: DEBUG:   Outside increment scheguled time
Jul  2 02:00:46 t1001 Parity Check Tuning: Outside times for increments so not resuming
Jul  2 02:00:46 t1001 Parity Check Tuning: TESTING:MONITOR ----------- MONITOR end ------

 

[itimpi]

@DontWorryScro Something strange going on as it appears that the plugin thinks the check was manually paused rather than being paused by the plugin which was why it was not resuming.  I will have to check to see if I can work out a scenario where that can happen.   Also worth mentioning that you do not seem to be on the very latest version of the plugin, but the last update was largely cosmetic so should not be relevant.

 

if I cannot work out why your issue arose are you prepared to try to repeat your issue with the Testing mode logging active in the plugin?   That can generate a LOT of additional logging but it does give detailed information on the internal workings of the plugin that is of value to me.

[DontWorryScro]

7 minutes ago, itimpi said:

@DontWorryScro Something strange going on as it appears that the plugin thinks the check was manually paused rather than being paused by the plugin which was why it was not resuming.  I will have to check to see if I can work out a scenario where that can happen.   Also worth mentioning that you do not seem to be on the very latest version of the plugin, but the last update was largely cosmetic so should not be relevant.

 

if I cannot work out why your issue arose are you prepared to try to repeat your issue with the Testing mode logging active in the plugin?   That can generate a LOT of additional logging but it does give detailed information on the internal workings of the plugin that is of value to me.

 

My rebuild has completed however I do have another drive that I have been meaning to swap in which will require another 3 day rebuild.  If need be I am willing to take steps to help you troubleshoot what is going on.  I manually made the fixes to the php file that were represented in the pull request by user robobub two posts before this.  Not sure if that will have any effect but thought I'd let you know.

[itimpi]

4 hours ago, DontWorryScro said:

I manually made the fixes to the php file that were represented in the pull request by user robobub two posts before this.  Not sure if that will have any effect but thought I'd let you know.

I have not had a chance to review his change as I have been away from home this last weekend,, but it should be irrelevant to the issue you seem to have.

[PhilDG]

Hi, like some others here, my log file is getting filled with the following every 6 minutes during a scheduled parity check - I couldn't see if there is an answer to this as yet

[DontWorryScro]

On 7/2/2023 at 4:18 PM, itimpi said:

@DontWorryScro Something strange going on as it appears that the plugin thinks the check was manually paused rather than being paused by the plugin which was why it was not resuming.  I will have to check to see if I can work out a scenario where that can happen.   Also worth mentioning that you do not seem to be on the very latest version of the plugin, but the last update was largely cosmetic so should not be relevant.

 

if I cannot work out why your issue arose are you prepared to try to repeat your issue with the Testing mode logging active in the plugin?   That can generate a LOT of additional logging but it does give detailed information on the internal workings of the plugin that is of value to me.

 

Turns out one of my parity drives fell off again last night so I replaced all the data and power cables to that cluster of drives and am rebuilding now.  This means I will be able to test this again when Mover runs tonight.  Ill activate the testing mode you mentioned to see if I can capture what is going on if it does in fact repeat itself.

Edited July 3, 2023 by DontWorryScro

[MrYoshii]

Is there a way to auto shutdown the server after parity check?

[itimpi]

3 hours ago, MrYoshii said:

Is there a way to auto shutdown the server after parity check?

Not using the plugin. 

 

The easiest way might be to consider writing a User Script that you initiate after the parity check is started that keeps looking to see if the check is still running, and if not issues a shutdown.

 

Technically it would be easy to add a feature like this to the plugin but since it can be hard to accurately predict when a check would finish I am not sure how useful it would be in practice.  You might find the system suddenly shutting down unexpectedly while you were using the server.   If you can make a good Use Case for this feature I can consider adding it in a future plugin update (with the default being to NOT auto-shutdown).

[itimpi]

20 hours ago, PhilDG said:

Hi, like some others here, my log file is getting filled with the following every 6 minutes during a scheduled parity check - I couldn't see if there is an answer to this as yet

You should not (as far as I know be getting this if you are up-to-date with the plugin.  I do not see it in my testing but there may be something I have not set correctly to rigger this.

 

If you ARE up-to-date then you can try enabling Settings->PHP Settings and set it to show all errors.   You should then see an entry to coincide with the syslog entries that gives the line number in my code where things are going wrong.  Letting me know that should make it easy to pinpoint the cause and thus fix it.

[DontWorryScro]

On 7/2/2023 at 8:41 PM, itimpi said:

I have not had a chance to review his change as I have been away from home this last weekend,, but it should be irrelevant to the issue you seem to have.

 

ok with Testing mode on the failure to resume the data rebuild occurred again over night.  The rebuild is still paused as I type this, even over 7 hours after the mover operation finished. 

 

Diagnostics attached.

 

Edit: I also just now noticed after posting this that there was a Parity Check Tuning plugin update available to me now.  I've gone ahead and updated.  I also manually restarted the Parity-Sync.

 

2nd Edit: Shortly there after I notification popped up from Parity Check Tuning at 12:42 that "[SNUTS] mover no longer running"

I'll just paste in the additional information that can be found from the logs after I manually resumed the parity-sync:

 

Jul 4 12:40:03 Snuts kernel: mdcmd (41): check resume Jul 4 12:40:03 Snuts kernel: md: recovery thread: recon P ... 
Jul 4 12:40:15 Snuts Parity Check Tuning: TESTING: ... not a parity check so always treat it as an automatic operation 
Jul 4 12:40:15 Snuts Parity Check Tuning: TESTING: actionDescription(recon P, 1, AUTOMATIC, 1) = Parity Sync/Data Rebuild 
Jul 4 12:40:15 Snuts Parity Check Tuning: DEBUG: Parity Sync/Data Rebuild running 
Jul 4 12:40:22 Snuts root: plugin: running: anonymous 
Jul 4 12:40:22 Snuts root: plugin: creating: /boot/config/plugins/parity.check.tuning/parity.check.tuning-2023.07.04.txz - downloading from URL https://raw.githubusercontent.com/itimpi/parity.check.tuning/master/archives/parity.check.tuning-2023.07.04.txz 
Jul 4 12:40:22 Snuts root: plugin: running: /boot/config/plugins/parity.check.tuning/parity.check.tuning-2023.07.04.txz 
Jul 4 12:40:22 Snuts root: plugin: running: anonymous 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING: ... not a parity check so always treat it as an automatic operation 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING: actionDescription(recon P, 1, AUTOMATIC, 1) = Parity Sync/Data Rebuild 
Jul 4 12:40:22 Snuts Parity Check Tuning: DEBUG: Parity Sync/Data Rebuild running 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG ----------- CONFIG begin ------ 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG /boot/config/forcesync marker file present 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG tidy marker file present 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG progress marker file present 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG automatic marker file present 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG paused marker file present 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG disks marker file present 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG mover marker file present 
Jul 4 12:40:22 Snuts Parity Check Tuning: Versions: Unraid 6.11.5, Plugin Version: 2023.06.25 
Jul 4 12:40:22 Snuts Parity Check Tuning: Configuration: Array#012(#012 [parityTuningScheduled] => 0#012 [parityTuningManual] => 0#012 [parityTuningAutomatic] => 0#012 [parityTuningFrequency] => 0#012 [parityTuningResumeCustom] => 5,15,25,35,45,55 * * * *#012 [parityTuningResumeDay] => 0#012 [parityTuningResumeHour] => 1#012 [parityTuningResumeMinute] => 15#012 [parityTuningPauseCustom] => 0,10,20,30,40,50 * * * *#012 [parityTuningPauseDay] => 0#012 [parityTuningPauseHour] => 7#012 [parityTuningPauseMinute] => 30#012 [parityTuningNotify] => 1#012 [parityTuningRecon] => 0#012 [parityTuningClear] => 0#012 [parityTuningRestart] => 1#012 [parityTuningMover] => 1#012 [parityTuningBackup] => 1#012 [parityTuningHeat] => 0#012 [parityTuningHeatHigh] => 3#012 [parityTuningHeatLow] => 8#012 [parityTuningHeatNotify] => 1#012 [parityTuningHeatShutdown] => 0#012 [parityTuningHeatCritical] => 2#012 [parityTuningHeatTooLong] => 30#012 [parityTuningLogging] => 2#012 [parityTuningLogTarget] => 0#012 [parityTuningMonitorDefault] => 17#012 [parityTuningMonitorHeat] => 7#012 
Jul 4 12:40:22 Snuts Parity Check Tuning: TESTING:CONFIG Creating required cron entries 
Jul 4 12:40:22 Snuts Parity Check Tuning: DEBUG: Created cron entry for 6 minute interval monitoring 
Jul 4 12:40:23 Snuts Parity Check Tuning: DEBUG: Updated cron settings are in /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron 
Jul 4 12:40:23 Snuts Parity Check Tuning: TESTING:CONFIG ----------- CONFIG end ------ 
Jul 4 12:40:23 Snuts root: plugin: parity.check.tuning.plg updated 
Jul 4 12:40:30 Snuts Parity Check Tuning: TESTING: ... not a parity check so always treat it as an automatic operation 
Jul 4 12:40:30 Snuts Parity Check Tuning: TESTING: actionDescription(recon P, 1, AUTOMATIC, 1) = Parity Sync/Data Rebuild 
Jul 4 12:40:30 Snuts Parity Check Tuning: DEBUG: Parity Sync/Data Rebuild running 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING: ... not a parity check so always treat it as an automatic operation 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING: actionDescription(recon P, 1, AUTOMATIC, 1) = Parity Sync/Data Rebuild 
Jul 4 12:42:24 Snuts Parity Check Tuning: DEBUG: Parity Sync/Data Rebuild running 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR ----------- MONITOR begin ------ 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR /boot/config/forcesync marker file present 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR tidy marker file present 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR progress marker file present 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR automatic marker file present 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR paused marker file present 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR disks marker file present 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR mover marker file present 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR isArrayOperationActive - parityTuningActive:1, parityTuningPos:2622003844 Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR ... not a parity check so always treat it as an automatic operation 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR backGroundTaskHandling: configName=parityTuningMover, value=1, isMoverRunning=0, Array: Active=1, Paused=0 Jul 4 12:42:24 Snuts Parity Check Tuning: Send notification: mover no longer running: 
Jul 4 12:42:24 Snuts Parity Check Tuning: TESTING:MONITOR ... using /usr/local/emhttp/webGui/scripts/notify -e Parity Check Tuning -i normal -l /Settings/Scheduler -s [SNUTS] mover no longer running 
Jul 4 12:42:25 Snuts Parity Check Tuning: TESTING:MONITOR Deleted mover marker file 
Jul 4 12:42:25 Snuts Parity Check Tuning: TESTING:MONITOR Deleted paused marker file 
Jul 4 12:42:25 Snuts Parity Check Tuning: TESTING:MONITOR ... no action required as array operation not paused 
Jul 4 12:42:25 Snuts Parity Check Tuning: TESTING:MONITOR backGroundTaskHandling: configName=parityTuningBackup, value=1, isBackupRunning=0, Array: Active=1, Paused=0 Jul 4 12:42:25 Snuts Parity Check Tuning: TESTING:MONITOR Temperature monitoring switched off 
Jul 4 12:42:25 Snuts Parity Check Tuning: TESTING:MONITOR ----------- MONITOR end ------ 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING: ... not a parity check so always treat it as an automatic operation 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING: actionDescription(recon P, 1, AUTOMATIC, 1) = Parity Sync/Data Rebuild 
Jul 4 12:48:26 Snuts Parity Check Tuning: DEBUG: Parity Sync/Data Rebuild running 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR ----------- MONITOR begin ------ 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR /boot/config/forcesync marker file present 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR tidy marker file present 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR progress marker file present 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR automatic marker file present 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR disks marker file present 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR isArrayOperationActive - parityTuningActive:1, parityTuningPos:2642689172 Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR ... not a parity check so always treat it as an automatic operation 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR backGroundTaskHandling: configName=parityTuningMover, value=1, isMoverRunning=0, Array: Active=1, Paused=0 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR backGroundTaskHandling: configName=parityTuningBackup, value=1, isBackupRunning=0, Array: Active=1, Paused=0 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR Temperature monitoring switched off 
Jul 4 12:48:26 Snuts Parity Check Tuning: TESTING:MONITOR ----------- MONITOR end ------

 

snuts-diagnostics-20230704-1236.zip

Edited July 4, 2023 by DontWorryScro

[MrYoshii]

7 hours ago, itimpi said:

Not using the plugin. 

 

The easiest way might be to consider writing a User Script that you initiate after the parity check is started that keeps looking to see if the check is still running, and if not issues a shutdown.

 

Technically it would be easy to add a feature like this to the plugin but since it can be hard to accurately predict when a check would finish I am not sure how useful it would be in practice.  You might find the system suddenly shutting down unexpectedly while you were using the server.   If you can make a good Use Case for this feature I can consider adding it in a future plugin update (with the default being to NOT auto-shutdown).

ok yes, thanks for that hint.
I think my use case may be very special ^^
I have two unraid servers, the main one is online 24/7 and the second one starts every day for a backup and after that it shuts down again. But on the Backup server I also want to run parity checks, but I don't want to manually think about them, so I would just auto start the server and after the check is done it should shut down itself again.

[itimpi]

3 hours ago, DontWorryScro said:

Edit: I also just now noticed after posting this that there was a Parity Check Tuning plugin update available to me now.  I've gone ahead and updated.  I also manually restarted the Parity-Sync.

The update should not be relevant to your issue but no point in not using the latest version  

 

I have looked through the diagnostics that you provided and the strange thing I see is that I can see at 01:48:33 that the plugin's monitor task started but then I do not see it finishing!   At this point the plugins monitor task seems to stop running.   Since it is that that is meant to detect the mover has finished and it is time to resume the array operation the fact the monitor task is not running explains why the operation was not resumed.   However I know of no obvious reason that the monitor task should stop running - the only thing that should change is the frequency depending on whether the plugin thinks it is idling or not.     If you get the situation occurring again can you perhaps go into the console level and let me have the results of running

 cat /etc/cron.d/root

so I can check that it still contains the entries for running the monitor task at regular intervals.

[itimpi]

25 minutes ago, MrYoshii said:

ok yes, thanks for that hint.
I think my use case may be very special ^^
I have two unraid servers, the main one is online 24/7 and the second one starts every day for a backup and after that it shuts down again. But on the Backup server I also want to run parity checks, but I don't want to manually think about them, so I would just auto start the server and after the check is done it should shut down itself again.

 

That seems a valid Use Case so I may go ahead and add the option to close down the server when an array operation finished.   Of course I may then find it is not as easy to implement as I currently think is the case  

[DontWorryScro]

18 minutes ago, itimpi said:

The update should not be relevant to your issue but no point in not using the latest version  

 

I have looked through the diagnostics that you provided and the strange thing I see is that I can see at 01:48:33 that the plugin's monitor task started but then I do not see it finishing!   At this point the plugins monitor task seems to stop running.   Since it is that that is meant to detect the mover has finished and it is time to resume the array operation the fact the monitor task is not running explains why the operation was not resumed.   However I know of no obvious reason that the monitor task should stop running - the only thing that should change is the frequency depending on whether the plugin thinks it is idling or not.     If you get the situation occurring again can you perhaps go into the console level and let me have the results of running

 cat /etc/cron.d/root

so I can check that it still contains the entries for running the monitor task at regular intervals.

 

 

this?

 

root@Snuts:~# cat /etc/cron.d/root
# Generated docker monitoring schedule:
10 0 * * * /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate check &> /dev/null

# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
40 1 * * * /usr/local/sbin/mover |& logger

# Generated parity check schedule:
0 3 * 2,5,8,11 0 [[ $(date +%e) -le 7 ]] && /usr/local/sbin/mdcmd check  &> /dev/null || :

# Generated plugins version check schedule:
10 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null

# Generated btrfs scrub cache nvme schedule:
25 2 7 * * /usr/local/emhttp/plugins/dynamix/scripts/btrfs_scrub start /mnt/cache_nvme -r &> /dev/null

# Generated Unraid OS update check schedule:
11 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null

# Generated Schedule for CA Auto Turbo Mode
0 0 * * * /usr/local/emhttp/plugins/ca.turbo/scripts/turboSchedule.php disable 420 > /dev/null 2>&1
# Generated cron settings for docker autoupdates
10 2 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1
# Generated cron settings for plugin autoupdates
5 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1

# CRON for CA background scanning of applications
35 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

# Generated system data collection schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null

# Generated schedules for parity.check.tuning
*/6 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

# Purge recycle bin at 5:00 AM on the first day of the week:
0 5 * * 0 /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin cron &> /dev/null

# Refresh Recycle Bin trash sizes every five minutes:
*/5 * * * * /usr/local/emhttp/plugins/recycle.bin/scripts/get_trashsizes &> /dev/null

# Generated cron schedule for user.scripts
*/10 * * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/chown_soulseek_complete/script > /dev/null 2>&1
0 */1 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/delete media that is stuck/script > /dev/null 2>&1

[itimpi]

That shows the entry to run the monitor task every 6 minutes is still there, so I m not sure why it has stopped being run.   It is late here so I need to sleep on it and hope some inspiration strikes  

[dopeytree]

 

Jul  5 08:41:12 Moulin-rouge Parity Check Tuning: Send notification: Array stopping: Restart will be attempted on next array start: Automatic Correcting Parity-Check (62.3% completed) 

 

When this situation arrises paused 62.3% is it possible to have an option to continue the saved (paused) parity check or option2 start a new one. 

 

Jul 5 09:06:29 Moulin-rouge Parity Check Tuning: ERROR: marker file found for both scheduled and automatic P

 

The default is to disregard the saved (paused) option. Making it slightly less useful as an option. 

 

 

moulin-rouge-diagnostics-20230705-0933.zip

Edited July 5, 2023 by dopeytree

[itimpi]

32 minutes ago, dopeytree said:

When this situation arrises paused 62.3% is it possible to have an option to continue the saved (paused) parity check or option2 start a new one. 

Don't see much point in this.    You can always manually stop the restarted one and then continue from there.

[PhilDG]

On 7/4/2023 at 4:17 PM, itimpi said:

You should not (as far as I know be getting this if you are up-to-date with the plugin.  I do not see it in my testing but there may be something I have not set correctly to rigger this.

 

If you ARE up-to-date then you can try enabling Settings->PHP Settings and set it to show all errors.   You should then see an entry to coincide with the syslog entries that gives the line number in my code where things are going wrong.  Letting me know that should make it easy to pinpoint the cause and thus fix it.

 

Thanks for your quick reply - there was an update available to me which I have installed - will keep an eye when my next parity check starts 
Thanks again for your help

[dopeytree]

I cancel a parity check - why does it keep restarting the next day?

 

It IS set to allow a check everyday BUT only every 4 months...

 

 

[itimpi]

That is nothing to do with the plugin as it never initiates the parity checks.   It must be a bug in the core Unraid system that does not handle correctly your settings.

 

To be honest, I cannot see what you are trying to achieve.     Why would you want to start a parity check every day during some months, and not at all during other months.

[dopeytree]

The parity check schedule is the 1st of every 4th month. This can be any day.

 

After I skipped a parity check, For some reason unraid was continuing to start a parity check the next day.

[itimpi]

1 hour ago, dopeytree said:

The parity check schedule is the 1st of every 4th month. This can be any day.

 

After I skipped a parity check, For some reason unraid was continuing to start a parity check the next day.

I am not sure that is how your settings are being interpreted 😊.  It might be worth looking at the entry that has been generated in /etc/cron.d/root to see what is actually set.

[dopeytree]

What's the best way to look at a file in the ram system i.e /etc/cron.d/root

I'm still working out how unraids terminal commands work compared to normal linux.

 

The system error is this thats causing the conflict:

Jul 11 10:06:30 Moulin-rouge Parity Check Tuning: ERROR: marker file found for both scheduled and automatic  P

[Boergen]

Just wanted to share that the latest scheduled (quarterly) parity check ran without any issues over a course of 10 days. I also updated the plugin versions in between.

 

This is only the second time it worked without manual intervention, so hopefully the latest changes helped with restarting a paused check reliably.