[Plugin] Parity Check Tuning


Recommended Posts

2 hours ago, rix said:

Hi, this lovely plugin is central to my build not overheating, but it just did.

My parity check was not paused, so my parity drive heated up to 66°C...

 

According to the logs and web UI there is a syntax error in the current version:

grafik.png.d77ca92c494301196e415c7c06b0f4ec.png

grafik.thumb.png.a24654f47613127eab7731da9ad44e7a.png

grafik.png.7a42403e97f27587b3e155a13662829d.png

 

Also this option always reverts to "No" ("Nein" as translated) - no notifications can be enabled..

 

grafik.png.ae5da5076a04808538d9a72fac47e8cd.png

 

Please fix ;)

 

What version are you running?  The syntax error you are seeing was should be fixed in yesterday's release (2021-03-30) that was introduced in the 2021-03-29 release the previous day.  If you DO have the latest release let me know so I can work out what information might help diagnose the problem.  

 

If you do NOT have the latest release then I think you will find updating to is also fixes your other problems as the syntax error stops the plugin executing correctly.

 

 

Link to comment

On the latest v3-30 plugin and this morning's parity check did not pause. Furthermore, if I try to set a different time for the pause while the parity check is running, 95% of the time the changes don't stick when hitting "apply". (i.e. changing the pause and resume times). I can toggle the scheduled check to yes or no, but the times usually don't change. I also tried reinstalling the plugin but the same behavior was exhibited. I'm on unraid 6.9.1.

EDIT: Changing increment frequency to custom and changing the pause/resume times with crontab format work, but I can't enable sending notifications for pause or resume of increments. Strange.  I guess we'll see if it pauses at half past the hour, but it didnt at the top of the hour previously.


EDIT 2: No joy. 30 7 * * * pause time had no affect and the parity check continues. Nothing in the log.

EDIT 3: Changed the log level to testing (derp. Should have done that to begin with when I discovered it didn't work). Looks like the plugin thinks I kicked off a manual parity check, when it's actually a scheduled one:
 

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ----------- PAUSE begin ------

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: DEBUG: Pause request

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: /boot/config/forcesync marker file present

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: progress marker file present

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: manual marker file present

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: disks marker file present

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ... appears to be manual parity check

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ...configured action for MANUAL Correcting Parity Check: 0

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ----------- PAUSE end ------

 

EDIT 4: Set "Use Increments for manual parity check" to "Yes" (for testing. Would prefer this to be off regularly) and it paused at the next scheduled time ( I set it to 40 7 * * * ). So, it pauses, but I guess it thought my scheduled check was manual somehow. That seems to be the conclusion of my report.

Edited by Schwiing
Link to comment

I have the latest version (and did not change settings since a while) and it paused correctly my monthly parity check

 

wxith a litlle mistake '%%" :

[TOWER] Paused

9 hours ago

Parity Check Tuning Correcting Parity Check (84.0%% completed)

Edited by dada051
Link to comment
43 minutes ago, Schwiing said:

On the latest v3-30 plugin and this morning's parity check did not pause. Furthermore, if I try to set a different time for the pause while the parity check is running, 95% of the time the changes don't stick when hitting "apply". (i.e. changing the pause and resume times). I can toggle the scheduled check to yes or no, but the times usually don't change. I also tried reinstalling the plugin but the same behavior was exhibited. I'm on unraid 6.9.1.

EDIT: Changing increment frequency to custom and changing the pause/resume times with crontab format work, but I can't enable sending notifications for pause or resume of increments. Strange.  I guess we'll see if it pauses at half past the hour, but it didnt at the top of the hour previously.


EDIT 2: No joy. 30 7 * * * pause time had no affect and the parity check continues. Nothing in the log.

EDIT 3: Changed the log level to testing (derp. Should have done that to begin with when I discovered it didn't work). Looks like the plugin thinks I kicked off a manual parity check, when it's actually a scheduled one:
 



Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ----------- PAUSE begin ------

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: DEBUG: Pause request

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: /boot/config/forcesync marker file present

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: progress marker file present

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: manual marker file present

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: disks marker file present

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ... appears to be manual parity check

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ...configured action for MANUAL Correcting Parity Check: 0

Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ----------- PAUSE end ------

 

EDIT 4: Set "Use Increments for manual parity check" to "Yes" (for testing. Would prefer this to be off regularly) and it paused at the next scheduled time ( I set it to 40 7 * * * ). So, it pauses, but I guess it thought my scheduled check was manual somehow. That seems to be the conclusion of my report.


was this a new check or the original check still running?    The reason for asking is that if it was the original scheduled check then the plugin would not have caught the start due to the syntax error, and in such a case would assume that it must be a manual check as they do not have an event the plugin can catch so manual is then assumed by default.

 

I wonder if it is worth me thinking about making a change to the logging so that there is a mode similar to the current ‘Testing’ mode where all log messages from the plugin are written to a log file in the plugins folder on the flash drive instead of or perhaps as well as the syslog.   This would give an easier way of seeing all plug-in messages for a complete run without filling up the syslog and would give a file it is easy for someone to send to me.  The original reason for using syslog was it often helps to see what the plugin was doing timewise relative to other things going on at the unRaid level.    Maybe use some radio buttons or check boxes opposite the logging option in Settings to allow the destination to be specified?  Logging to syslog does have the advantage of only going to RAM so avoiding unnecessary writes to the flash drive.   I’ll think about that as it should be easy to do and may well help with support.

Link to comment
6 minutes ago, itimpi said:


was this a new check or the original check still running?    The reason for asking is that if it was the original scheduled check then the plugin would not have caught the start due to the syntax error, and in such a case would assume that it must be a manual check as they do not have an event the plugin can catch so manual is then assumed by default.

 

I wonder if it is worth me thinking about making a change to the logging so that there is a mode similar to the current ‘Testing’ mode where all log messages from the plugin are written to a log file in the plugins folder on the flash drive instead of or perhaps as well as the syslog.   This would give an easier way of seeing all plug-in messages for a complete run without filling up the syslog and would give a file it is easy for someone to send to me.  The original reason for using syslog was it often helps to see what the plugin was doing timewise relative to other things going on at the unRaid level.    Maybe use some radio buttons or check boxes opposite the logging option in Settings to allow the destination to be specified?  Logging to syslog does have the advantage of only going to RAM so avoiding unnecessary writes to the flash drive.   I’ll think about that as it should be easy to do and may well help with support.

 

 

This was the original check that started at midnight on April 1st (Today). The pause time was scheduled for 0700 and when I checked at 0715, the check wasn't paused, then I started to troubleshoot.

Link to comment
22 minutes ago, Schwiing said:

 

 

This was the original check that started at midnight on April 1st (Today). The pause time was scheduled for 0700 and when I checked at 0715, the check wasn't paused, then I started to troubleshoot.


OK - sounds like the current issue is a side-effect of the fact the check started while there was a syntax error in the plugin and so there is probably not a new bug for me to fix.   If you see anything similar on a new check then please let me know.

 

33 minutes ago, whiskeyjr said:

New issue today.

The parity check started when programmed, but did not pause at 0800 as expected.  Instead, it continued for an additional half-hour and paused at 0830.  Any ideas?

 

image.png.fc5f813edd7fef6f97bc5826036f9403.png


can you please post (or just look at) the contents of the .cron file in the plugins folder on the flash drive.    That should show the times that have been set for the plugin related tasks to run.    If the pause and resume tasks do not agree with the values you have showing in settings then making a nominal change and hitting apply should cause that file to be regenerated.  
 

Having said that the message you are showing in the screen shot looks like a standard unRaid rather than one from the plugin so if you think the times in the .cron file look correct I would be interested in the syslog covering that period to see what shows up there.

Link to comment
1 hour ago, itimpi said:


OK - sounds like the current issue is a side-effect of the fact the check started while there was a syntax error in the plugin and so there is probably not a new bug for me to fix.   If you see anything similar on a new check then please let me know.

 

 

I'm confused. Wasn't the syntax error issue resolved with the 3-30 update? Or what syntax error are you referring to?

Edited by Schwiing
Link to comment
2 minutes ago, Schwiing said:

I'm confused. Wasn't the syntax error issue resolved with the 3-30 update? Or what syntax error are you referring to?

Yes - but if you had already started the check before the fix for the syntax error was released then the plugin would have missed the fact it was a scheduled check.

Link to comment
6 minutes ago, Schwiing said:

 

The check started on 4/1. The update was on 3-30. What am I missing?

Nothing if that is the case - I thought you had it started earlier.

 

Might want to check the times in the .cron file in the plugins folder are correct?  Also I am not sure if the switch to Summer time can affect such scheduling putting them an hour out?  Ad the moment I have not reproduced your issue.

 

I should shortly have the extra logging option available which would help with debugging.

 

 

 

Link to comment
2 minutes ago, itimpi said:

Nothing if that is the case - I thought you had it started earlier.

 

Might want to check the times in the .cron file in the plugins folder are correct?  Also I am not sure if the switch to Summer time can affect such scheduling putting them an hour out?  Ad the moment 

 

Looks correct to me:

 

0 0 * * * /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
17 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

 

Link to comment
1 minute ago, Schwiing said:

 

Looks correct to me:

 


0 0 * * * /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
17 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

 

 

Agreed - a bit puzzled at the moment why you get the behaviour you see.

Link to comment
Just now, Schwiing said:

 

I am too. Thanks for the quick replies and let me know if you want me to test anything else out for troubleshooting. 

Wait for me to get the version with logging to flash support released - should help with gathering useful diagnostics.  Hopefully that will either be later today or sometime tomorrow.

Link to comment
5 hours ago, itimpi said:


can you please post (or just look at) the contents of the .cron file in the plugins folder on the flash drive.    That should show the times that have been set for the plugin related tasks to run.    If the pause and resume tasks do not agree with the values you have showing in settings then making a nominal change and hitting apply should cause that file to be regenerated.  
 

 

Found this:

image.png.6004229f95aa15a794d78cced511fd5c.png

 

5 hours ago, itimpi said:

Having said that the message you are showing in the screen shot looks like a standard unRaid rather than one from the plugin so if you think the times in the .cron file look correct I would be interested in the syslog covering that period to see what shows up there.

 

Does this help?

image.png.d8c70b41fcfd86dcb8244fa7897396ad.png

Link to comment
7 hours ago, whiskeyjr said:

Here you go:

image.png.39ea7bc91d05d0b444f36085bf8f565b.png


That shows that at the moment the pause IS scheduled for 8:30 at the cron level which explains why the pause happened at 8:30.  
 

unRaid assumes any .cron file present in plugin’s folder contains entries to be added to those for the root user.  This file is regenerated if you make any change to the plugins settings so if you want a different time make a nominal change and hit Apply.   If you now examine the file you should see that the times for pause and resume match your current settings. 
 

My suspicion is that the last time you changed the plugin settings was when there was a syntax error in the underlying script file that stopped this file from being regenerated to match the new settings.

  • Like 1
Link to comment

I use this plugin since it was release. My Disks tend to overheat when not using it while parity check. 

 

But now there is a Problem because it stopped because of the "heat" of the disks which is not true.

 

All of my disks are configured to 45°C (warning disk temperature threshold) and 55°C (critical disk temperature threshold)

 

I get the notice:

Parity Check Tuning 02-04-2021 11:00

[SERVER] Pause

Following drives overheated: parity (25°C) disk1 (26°C) disk2 (26°C) disk3 (26°C) disk4 (26°C) disk5 (27°C) disk6 (25°C) disk7 (24°C) disk9 (25°C) parity2 (27°C)

Non-Correcting ParityCheck (0,1%% completed)

 

The "hottest" disk has a temperature of 27°C (about 80° Fahrenheit). Every single disk in this array has a temperature warning.

The server is on 6.9.1. 

 

I don't understand this warning, because it is not true, so why I get this? 

 

kind ragards

Nils

Link to comment
1 hour ago, Marino said:

I use this plugin since it was release. My Disks tend to overheat when not using it while parity check. 

 

But now there is a Problem because it stopped because of the "heat" of the disks which is not true.

 

All of my disks are configured to 45°C (warning disk temperature threshold) and 55°C (critical disk temperature threshold)

 

I get the notice:

Parity Check Tuning 02-04-2021 11:00

[SERVER] Pause

Following drives overheated: parity (25°C) disk1 (26°C) disk2 (26°C) disk3 (26°C) disk4 (26°C) disk5 (27°C) disk6 (25°C) disk7 (24°C) disk9 (25°C) parity2 (27°C)

Non-Correcting ParityCheck (0,1%% completed)

 

The "hottest" disk has a temperature of 27°C (about 80° Fahrenheit). Every single disk in this array has a temperature warning.

The server is on 6.9.1. 

 

I don't understand this warning, because it is not true, so why I get this? 

 

kind ragards

Nils

 

Not sure why you should get this if on the latest release of the plugin :( 

 

To help with diagnosing the cause can you install the new version of the plugin (2021-04-02) I have just released and then in the plugin's settings set the logging level to "Testing" and select the one of the options for logging to flash.   The plugin will now create a file called 'parity.tuning.log' in the plugins folder on the flash drive when it is running so if you can recreate the issue and let me have that file it should help me pinpoint where things are going wrong.

 

Link to comment
19 hours ago, Schwiing said:

 

I am too. Thanks for the quick replies and let me know if you want me to test anything else out for troubleshooting. 

 

I have just released the version of the plugin that will make it easy to create a log file on the flash drive when logging level is set as Testing.   I would be grateful if you can set that to be active ; recreate your issue; and then send me the resulting log file.

  • Like 1
Link to comment
6 hours ago, Squid said:

Seems to only happen if the plugin is installed:

 

image.png.5abae015bf4852a1dc2373ac956d0df0.png

 

The plugin replaces the standard script with a slightly enhanced version that handles the extra fields the plugin handles to display history records which explains why you only see that error if the  plugin is installed.   Looks like something has crept into the multi-language support part of the script although I am not sure yet what it is.   Thinking about it I have not checked the changes to produce the enhanced script against the standard 6.9.1 version.

 

I have been able to reproduce this so will be able to fix it.  Interestingly it happens in one of my test 6.9.1 systems but not another one on that same release.   Not sure yet of the cause but I am sure it will be relatively easy to track down and fix.  Thanks for reporting this.

 

 

  • Thanks 1
Link to comment
21 hours ago, Squid said:

Seems to only happen if the plugin is installed:

 

image.png.5abae015bf4852a1dc2373ac956d0df0.png

 

Just thought I would let you know that tracking down the cause of this bug is proving more elusive than I had expected.  As I mentioned I can reproduce this bug on one 6.9.1 system and not another.  I have checked and they both have identical copies of the script for displaying the history, and on one it works without error and the other displays the error you see.  Still trying to pin down the difference that causes this issue.

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.