[Plugin] Parity Check Tuning


Recommended Posts

Strange - that looks like a valid command :( 

 

Are you sure it is 15 minutes?     There should not be anything at exactly that interval (although 17 minutes is a possibility but that should not be a “pause” type entry).  
 

Can you supply a copy of the file parity.tuning.cron from the plugins folder on your flash drive?     That contains the entries that are used for the plugin to work with cron.   It is regenerated any time you make a change in the plugin’s settings to be appropriate for the current settings so it might be worth doing that to see if it magically ‘cures’ the problem.

 

The parity.tuning.cfg file would also be useful to show exactly what settings you are running with to help with trying to recreate your exact scenario on my test systems.   In fact the other files in that folder (except the txz one) could all help give a better idea of what exactly is happening.

Link to comment

Log:

Feb 8 23:04:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 8 23:04:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
Feb 8 23:19:01 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 8 23:19:01 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
Feb 8 23:34:01 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 8 23:34:01 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
Feb 8 23:48:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 8 23:48:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
Feb 9 00:03:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null

 

parity.check.tuning.cron

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

 

parity.tuning.cfg

parityTuningIncrements="yes"
parityTuningFrequency="daily"
parityTuningResumeCustom=""
parityTuningResumeHour="23"
parityTuningResumeMinute="0"
parityTuningPauseCustom=""
parityTuningPauseHour="7"
parityTuningPauseMinute="0"
parityTuningUnscheduled="yes"
parityTuningRecon="no"
parityTuningClear="no"
parityTuningNotify="no"
parityTuningHeat="yes"
parityTuningHeatHigh="2"
parityTuningHeatLow="10"
parityTuningHeatNotify="yes"
parityTuningDebug="no"
parityTuningHeatShutdown="yes"
parityTuningHeatCritical="1"

 

parity-checks.log parity.check.tuning.progress.save

Link to comment
Quote

It is regenerated any time you make a change in the plugin’s settings to be appropriate for the current settings so it might be worth doing that to see if it magically ‘cures’ the problem.

 

Just went into settings again and saved (no changes). New parity.check.tuning.cron:

# Generated schedules for parity.check.tuning
0 23 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
0 7 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
*/7 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

 

I'm guessing that fixed the issue - will check in the morning.

Link to comment
49 minutes ago, LateNight said:

 

Just went into settings again and saved (no changes). New parity.check.tuning.cron:


# Generated schedules for parity.check.tuning
0 23 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
0 7 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
*/7 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

 

I'm guessing that fixed the issue - will check in the morning.


Thanks for the information.   Glad to hear that going through the settings screen seems to have fixed the issue.

 

There was an internal change to the way that the configuration information was stored.   I can see that the .cfg file you posted is still in the old format.  I thought I had put in place the code that migrated old format to new one but it looks like I missed an entry that affects the generation of the cron entries.  Using the information you have provided I can fix this but hopefully it is a short term issue.

Link to comment

Has anyone tried out the Parity Problems Assistant?

 

At the moment I have set it up to not allow you to do anything if there is no parity disk present.   It occurred to me that in such a case I could allow a partial read-check rather than a parity-check.  Not sure if there are real-world scenarios where this might be useful?

Link to comment
9 hours ago, itimpi said:


Thanks for the information.   Glad to hear that going through the settings screen seems to have fixed the issue.

 

There was an internal change to the way that the configuration information was stored.   I can see that the .cfg file you posted is still in the old format.  I thought I had put in place the code that migrated old format to new one but it looks like I missed an entry that affects the generation of the cron entries.  Using the information you have provided I can fix this but hopefully it is a short term issue.

 

Going in and saving again, without making changes, fixed the issue. No log entries overnight. Thank you.

Link to comment
3 hours ago, itimpi said:

Has anyone tried out the Parity Problems Assistant?

 

At the moment I have set it up to not allow you to do anything if there is no parity disk present.   It occurred to me that in such a case I could allow a partial read-check rather than a parity-check.  Not sure if there are real-world scenarios where this might be useful?

I'd be willing to try it if it were compatible with stable. Is there an incompatibility issue?

Link to comment
1 hour ago, Schwiing said:

I'd be willing to try it if it were compatible with stable. Is there an incompatibility issue?


The basic plugin functionality to handle pause/resume of parity checks (and other array operations) and using increments works on all recent releases

 

the features that require the 6.9.0 rc release are:

  • restarting parity checks from the point reached that were in progress when the system is shutdown or rebooted
  • the Partial parity checks used by the Parity Problems Assistant.

These options are not available on the 6.8.3 release as they rely on some new low level functionality that is only present in the 6.9.0 rc releases.  If running on 6.8.3 the GUI will highlight what options cannot be used.   I had to decide between hiding such options in the GUI or leaving them visible (but disabled) with a message stating why they were disabled and went for leaving them visible.

 

Many people now seem to think the current 6.9.0 rc2 stable to be used for their normal daily use. Hopefully 6.9.0 is not too far off leaving rc status and becoming the new stable release.  

Link to comment
2 minutes ago, itimpi said:


The basic plugin functionality to handle pause/resume of parity checks (and other array operations) and using increments works on all recent releases

 

the features that require the 6.9.0 rc release are:

  • restarting parity checks from the point reached that were in progress when the system is shutdown or rebooted
  • the Partial parity checks used by the Parity Problems Assistant.

These options are not available on the 6.8.3 release as they rely on some new low level functionality that is only present in the 6.9.0 rc releases.   If running on 6.8.3 the GUI will highlight what options cannot be used.   I had to decide between hiding such options in the GUI or leaving them visible (but disabled) with a message stating why they were disabled and went for leaving them visible.

 

Many people now seem to think the current 6.9.0 rc2 stable to be used for their normal daily use. Hopefully 6.9.0 is not too far off leaving rc status and becoming the new stable release.  

Cool, no worries, and thanks for the explanation.

 

As long as it pauses and resumes properly for scheduled runs on stable, I'm happy :)

Link to comment

Unraid 6.8.3, I had the same issue for the last few days, a "failed parsing crontab" log alternating between resume and pause every 15min. I updated the Parity Check Tuning plugin and did what was suggest: Visit the plugin page, change a setting back and forth so the "APPLY" button appears, save and the issue didn't return... hopping to wait until 6.8.9 to update 🤞

Link to comment

I tested the new version over the last couple of nights with a scheduled parity check with one pause.  Everything worked correctly and the start and end notifications were as expected.  Emails for start, pause, resume and finish were also sent.  This is looking very good.  Many thanks for the improvements.  (I am running 6.9.0-rc2 btw.)

Link to comment

I am having difficulty getting my parity check to complete.  System logs show:

 

Feb 11 09:07:01 Tower parity.check.tuning.php: Paused Parity Sync/Data Rebuild  (0.5%% completed): Following drives overheated: parity(26) disk1(28) disk2(26) disk3(24) disk4(27)

 

I wouldn't consider any of these temperatures to be of concern since the ambient temperature in the house is 21-23.  Is there some way to adjust these settings?

Link to comment

You set what is to be considered ‘hot’.

 

You can set the warning and critical temperature thresholds for any drive (if to be different to the global setting) by clicking on it on the Main tab.

 

the parity check tuning plugin then allows you to specify how close to the warning threshold a drive should get before a pause is initiated (assuming you have even enabled the option for temperature related pause/resume).    At a guess it sounds to me as if you might have set an inappropriate value for this setting?

Link to comment
12 hours ago, ScottinOkla said:

I am not sure if this is related or not, but I am running 6.8.3 that I did a file level USB recovery due to a failed drive.  I did not previously have this issue with my exact configuration.

Don't see how that could matter.

 

I have not tracked down anything yet that can cause the exact symptoms you describe although I have identified an anomaly if the system is set to report temperatures in Fahrenheit, but that does not appear to apply to you.

Link to comment

Good morning itimpi, this may be related to the issue ScottinOkla is describing?

 

I had a parity check running all day yesterday (manually started), went to bed, woke up and it was paused for no reason.

 

I do have the parity check tuner plugin installed, and my only pause scenario is disks overheating. I see no indication in the logs that any disks were overheating (additionally my house has quite a cold ambient temperature).

 

I did have "Send notification for temperature related pause" set to NO, but I assume it would have still logged the pause and reason in the logs?

 

It stopped right at 3:30AM CST with no corresponding log entries around it as to why...

 

Feb 12 13:44:24 VOID webGUI: Successful login user root from 192.168.1.8
Feb 12 13:45:00 VOID root: Fix Common Problems Version 2021.01.27
Feb 12 13:47:23 VOID kernel: mdcmd (38): check nocorrect
Feb 12 13:47:23 VOID kernel: md: recovery thread: check P ...
Feb 12 13:47:48 VOID kernel: mdcmd (39): set md_write_method 1
Feb 12 13:47:48 VOID kernel: 
Feb 12 13:49:04 VOID root: Stopping Auto Turbo
Feb 12 13:49:04 VOID root: Setting write method to unRaid defined
Feb 12 13:49:04 VOID kernel: mdcmd (40): set md_write_method auto
Feb 12 17:04:35 VOID dhcpcd[1683]: br0: failed to renew DHCP, rebinding
Feb 12 18:19:34 VOID emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog 
Feb 12 23:00:01 VOID Plugin Auto Update: Checking for available plugin updates
Feb 12 23:00:06 VOID Plugin Auto Update: Checking for language updates
Feb 12 23:00:06 VOID Plugin Auto Update: Community Applications Plugin Auto Update finished
Feb 13 00:00:07 VOID crond[1849]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null
Feb 13 00:10:37 VOID emhttpd: spinning down /dev/sdh
Feb 13 00:10:37 VOID emhttpd: spinning down /dev/sdg
Feb 13 00:10:37 VOID emhttpd: spinning down /dev/sdb
Feb 13 00:10:37 VOID emhttpd: spinning down /dev/sdf
Feb 13 00:10:37 VOID emhttpd: spinning down /dev/sdq
Feb 13 00:10:37 VOID emhttpd: spinning down /dev/sdo
Feb 13 02:00:01 VOID Docker Auto Update: Community Applications Docker Autoupdate running
Feb 13 02:00:01 VOID Docker Auto Update: Checking for available updates
Feb 13 02:00:07 VOID Docker Auto Update: No updates will be installed
Feb 13 03:30:06 VOID kernel: mdcmd (49): nocheck PAUSE
Feb 13 03:30:06 VOID kernel: 
Feb 13 03:30:06 VOID kernel: md: recovery thread: exit status: -4
Feb 13 05:02:21 VOID emhttpd: read SMART /dev/sdh
Feb 13 05:02:29 VOID emhttpd: read SMART /dev/sdg
Feb 13 05:02:35 VOID emhttpd: read SMART /dev/sdb
Feb 13 05:02:42 VOID emhttpd: read SMART /dev/sdo
Feb 13 05:02:49 VOID emhttpd: read SMART /dev/sdf
Feb 13 05:02:54 VOID emhttpd: read SMART /dev/sdq

void-diagnostics-20210213-0521.zip

Edited by weirdcrap
Link to comment

At the moment I still have not managed to recreate this issue in any of my environments :(


There is no log entry automatically being created on a pause - there probably should have been.   There IS one created if you have notifications enabled but you are correct in that there should probably be one on a pause/resume regardless.

 

I have been sorting out some issues I have spotted which can arise if you have your system is set to use temperatures in Fahrenheit rather than Celsius, but I do not think these are the cause of the issue.

 

I am going to soon (probably tomorrow) upload a new version with all the odds-and-ends I have spotted resolved.    While I do not think it will solve the problem (as far as I can see) it will provide a basis against which I can ask someone to recreate the issue with Testing level logging enabled to see if I can spot what might be the reason for this behaviour.

  • Like 1
Link to comment

I am getting my log flooded with these messages every 12 mins on beta 30 and the latest version of parity check.

 

Feb 14 02:08:01 NAS crond[2118]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 14 02:08:01 NAS crond[2118]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null

 

Link to comment
32 minutes ago, TexasUnraid said:

I am getting my log flooded with these messages every 12 mins on beta 30 and the latest version of parity check.

 


Feb 14 02:08:01 NAS crond[2118]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 14 02:08:01 NAS crond[2118]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null

 


Have you tried going into the Settings, making a nominal change; and then pressing the Apply button?    That regenerates the cron entries.

Link to comment

 

I have pushed an update that includes a number of small updates. 

 

I have not, however, been able to reproduce the problem that has been reported of getting a parity check paused because the drives apparently overheat when they have not really done so.   It is possible that I have inadvertently fixed this issue but I am not optimistic.  I would be grateful therefore if someone who is experiencing this issue can

  • set the plugin to pause/resume a parity check on drive temperature
  • set the plugins logging level to "Testing"
  • recreate the issue for at least one unexpected pause
  • let me have the syslog (or system diagnostics as they include the syslog) covering this period so I can get a better idea of what is going wrong.
  • set the logging level back to a lower level to avoid filling up your syslog
  • disable pause/resume on drive temperature until I can report the issue has been resolved
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.