[Plugin] Parity Check Tuning


Recommended Posts

I'm having ongoing issues with my parity checking. About 80% of the checks return 2 errors on the same blocks. There doesn't seem to be an issue with the array, it's always the same 2 blocks, right at the end of the 20TB check.

 

I have had an issue for the last couple of months where the parity check history is not loading, although it is available on the flash, as detailed here:

 

The last time I ran a successful correcting parity check I used the command line. However, this time (a few weeks later) it's refusing to start and I'm not sure why. The array's started and everything else is working as it should as far as I can tell. Here's what I get:

root@Tower:~# parity.check correct
Not allowed as No array operation in progress already running

I can't find any other instances of that error message online.

I'm using the 2023.04.30 version of the plugin on v6.11.1 of Unraid.

Link to comment

The message should mean exactly what it says, but if you want me to look any further I would need a log taken with the testing mode active in the plugin settings.

 

in terms of the parity history not showing are you up-to-date with the plugin?   There was a issue with this happening on some Unraid releases but it was corrected a few plugin releases ago and should now work fine as far as I know.   What Unraid and plugin releases are you running?   If you post (or PM me) a copy of the config/parity-checks.log file from your flash drive I can try and reproduce your symptoms.

 

EDIT:  Just done some checking - and I may have broken some of the CLI commands.   I will do some testing to today and fix any issues I find.   I will also enhance the error messages to give more detailed information about any operation in progress.

Link to comment
  • 1 month later...

Hi,

 

For me, the Parity Check Tuning plugin only ever worked successfully once. Every other times, it paused (due to temperature) and never resumed.

 

When checking today (it's currently hanging again), I saw the following log spam:

Jun 11 13:06:25 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:12:42 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:18:46 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:24:43 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:30:35 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:32:12 unraid  emhttpd: spinning down /dev/sde
Jun 11 13:32:12 unraid  emhttpd: spinning down /dev/sdc
Jun 11 13:36:36 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:42:22 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:48:32 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:54:44 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

 

I also attached my diagnostics.

 

Could you maybe take a look at what's going on? :)
 

Thanks and best,

Boergen

unraid-diagnostics-20230611-1357.zip

Link to comment
2 hours ago, Boergen said:

Hi,

 

For me, the Parity Check Tuning plugin only ever worked successfully once. Every other times, it paused (due to temperature) and never resumed.

 

When checking today (it's currently hanging again), I saw the following log spam:

Jun 11 13:06:25 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:12:42 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:18:46 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:24:43 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:30:35 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:32:12 unraid  emhttpd: spinning down /dev/sde
Jun 11 13:32:12 unraid  emhttpd: spinning down /dev/sdc
Jun 11 13:36:36 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:42:22 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:48:32 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 11 13:54:44 unraid  crond[1229]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

 

I also attached my diagnostics.

 

Could you maybe take a look at what's going on? :)
 

Thanks and best,

Boergen

unraid-diagnostics-20230611-1357.zip 325.93 kB · 1 download

Can’t tell from the diagnostics what the problem might be.    The temperature mode is always very hard to simulate properly when testing so the most likely to not behave as expected.   Turning on the Testing mode logging in the plugin settings and letting it run for a short  while (about 30 minutes) and post new diagnostics it might give me an idea of what is going if the parity check is paused when it should be resumed.  Also make sure you are on the latest version of the plugin.

Link to comment

Hey there, I installed the Parity Check Tuning plugin last night and enabled the increments for a manual check option. My intention was to run a manual parity check for as long as I can until I need to pause it and then having it complete in increments in scheduled time. However, what I observed today is that despite not manually pausing the check at any point, it automatically paused it outside of the scheduled increment as it ended.

Jun 14 07:30:01 unraid Parity Check Tuning: Paused: Manual Correcting Parity-Check
Jun 14 07:30:06 unraid kernel: mdcmd (37): nocheck pause
Jun 14 07:30: 06 unraid kernel:
Jun 14 07:30:06 unraid kernel: m: recovery thread: exit status: -4
Jun 14 07:30:11 unraid Parity Check Tuning: Send notification: Paused: Manual Correcting Parity-Check (38.7% completed)
Jun 14 07:30:11 unraid Parity Check Tuning: ... but suppressed as system notifications do not appear to be enabled

For reference I am running 6.12.0-rc8.

Not a big issue, but thought I’d post in case it is a bug. Although I may have just done something wrong. My settings are attached.

B85C2D8A-B858-4AEC-BD8E-0CEF18135D25.jpeg

Link to comment
5 hours ago, Swarles said:

Hey there, I installed the Parity Check Tuning plugin last night and enabled the increments for a manual check option. My intention was to run a manual parity check for as long as I can until I need to pause it and then having it complete in increments in scheduled time. However, what I observed today is that despite not manually pausing the check at any point, it automatically paused it outside of the scheduled increment as it ended.

Jun 14 07:30:01 unraid Parity Check Tuning: Paused: Manual Correcting Parity-Check
Jun 14 07:30:06 unraid kernel: mdcmd (37): nocheck pause
Jun 14 07:30: 06 unraid kernel:
Jun 14 07:30:06 unraid kernel: m: recovery thread: exit status: -4
Jun 14 07:30:11 unraid Parity Check Tuning: Send notification: Paused: Manual Correcting Parity-Check (38.7% completed)
Jun 14 07:30:11 unraid Parity Check Tuning: ... but suppressed as system notifications do not appear to be enabled

For reference I am running 6.12.0-rc8.

Not a big issue, but thought I’d post in case it is a bug. Although I may have just done something wrong. My settings are attached.

B85C2D8A-B858-4AEC-BD8E-0CEF18135D25.jpeg

That is expected behaviour as the moment the plugin detects a Manual Check has been started and you have set the option to run manual checks in increments it will automatically pause the check if it is outside the increment period (ready to restart it when the next increment starts).

 

the only way you would achieve what you want is not enable the option to pause/resume manual checks until you are ready for the plugin to start doing this.

Link to comment
2 hours ago, itimpi said:

That is expected behaviour as the moment the plugin detects a Manual Check has been started and you have set the option to run manual checks in increments it will automatically pause the check if it is outside the increment period (ready to restart it when the next increment starts).

Oh ok, upon re-reading the explanation for the setting I can see how I misinterpreted it.

image.thumb.png.78401579396061575efdd17520144352.png

I thought that it only scheduled a manual parity check to continue in increments if two conditions were met: 1) a manual parity check had been started, 2) the manual parity check got paused. But I can now see this was only an explanation to demonstrate that the parity check would continue in scheduled increments and not a condition that needed to be met. Perhaps I could suggest an alternate description that may negate a misunderstanding like mine:

 

"With this option set to Yes; if you manually start a Parity Check from the Main page, the check will continue until the end of the next scheduled increment, and then use increments until the Parity Check is completed. Otherwise, if the Parity Check is manually paused, it will be resumed at the beginning of the next scheduled increment."

 

Feel free to use that if you want to change it or not if you think it'll just be more confusing or too long :)

 

Do you think it would be possible to implement the behaviour that I initially thought it would be without having to toggle the setting during a parity check? Without knowing how plugins, or the scheduler, or parity checks work, my initial thought would be to have some kind of flag parameter that is changed if a manual parity check is at any point manually paused. Then if this flag is set true, every time a scheduled increment starts or ends, it checks the flag and starts or pauses the parity check if it is true. Otherwise, if the manual parity check is then manually resumed, it sets the flag false. I'm not sure how difficult it would be to achieve something like this but I think it would be a very useful feature where you can run the parity check for as long as possible until you need better IO throughput, and then if you do manually pause it, it continues the check during scheduled increments until completion or until you manually resume it again. This way if you start a manual check at night with the intention of letting it run until midday where you might need to pause it, it doesn't automatically pause at the end of the first increment. I do see how this could be annoying for someone who just wants the manual check to be incremented, they could still achieve that result by starting the check and then immediately pausing it. I'd be happy to help in anyway I can if possible.

 

SORRY to bombard you with all of this, I just have one more question. I noticed my logs were getting spammed with this every 6 minutes:

Jun 15 00:12:35 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 15 00:18:43 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 15 00:24:33 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

Any idea why this is the case?

 

Thank you so much!

 

 

Link to comment
4 minutes ago, Swarles said:

SORRY to bombard you with all of this, I just have one more question. I noticed my logs were getting spammed with this every 6 minutes:

Jun 15 00:12:35 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 15 00:18:43 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 15 00:24:33 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

Any idea why this is the case?


That suggests something is going wrong in the periodic monitor task the plugin runs.   I will have to see if I can reproduce.   Can you please confirm what version of both Unraid and the plugin you are using to help with seeing if I can reproduce.

 

I will think about whether if there is any easy way to get the behaviour you describe.  The plugin is as far as possible stateless so knowing how one got to the state at any particular instance in time is not always easy to achieve.

 

 

Link to comment
6 minutes ago, itimpi said:


That suggests something is going wrong in the periodic monitor task the plugin runs.   I will have to see if I can reproduce.   Can you please confirm what version of both Unraid and the plugin you are using to help with seeing if I can reproduce.

Unraid: 6.12.0-rc8

Plugin: 2023.05.07

If it is any help, I don't recall seeing this log earlier in the day which leads me to believe it only started after I manually resumed the parity check (outside of a scheduled increment). This may just be a coincidence though. I tried setting "Use increments for manual Parity Check:" to "No" and the log still appeared.

 

 

Link to comment
19 hours ago, Swarles said:

Unraid: 6.12.0-rc8

Plugin: 2023.05.07

If it is any help, I don't recall seeing this log earlier in the day which leads me to believe it only started after I manually resumed the parity check (outside of a scheduled increment). This may just be a coincidence though. I tried setting "Use increments for manual Parity Check:" to "No" and the log still appeared.

 

 

 

I have not managed to reproduce this error unfortunately.

 

If the syslog entries are still happening is there any chance you could do the following?

  1. Enable the Testing log mode in the plugin settings
  2. Go to Tools->webGui->PHP settings and set the Error Reporting Level to All Categories
  3. Wait until you get another occurrence of the log entry - since you say they were every 6-7 minutes this should not take long

Send me a copy of your system's diagnostics (PM will do if you do not want to post them here) and any entries in the log shown by View Log on the PHP Settings page that refer to the Parity.Check.Tuning plugin.  Having done this you can set the settings you changed in 1) and 2) back to their default values to avoid getting excessive logging taking place.

 

Hopefully this would give me additional information that would allow me to pin down exactly why those log errors are occurring on your system.

 

Link to comment
5 hours ago, itimpi said:

 

I have not managed to reproduce this error unfortunately.

 

If the syslog entries are still happening is there any chance you could do the following?

Hey so, it appears as though the logs stopped happening after the parity check completed.

Next time I am running a parity check, I will observe the logs and if the error is happening I will go through the process of getting uou better log files. Thanks again :)

Link to comment
On 6/15/2023 at 5:12 PM, Swarles said:

Hey so, it appears as though the logs stopped happening after the parity check completed.

Next time I am running a parity check, I will observe the logs and if the error is happening I will go through the process of getting uou better log files. Thanks again :)

Thought it was worth mentioning that the latest plugin update should now behave as you expected (at least it appears to in my testing).   

 

I have also added putting an entry in the syslog when a manual action is detected (although it my take a few minutes for the plugin to detect it) which should help make it clearer if something is happening that is not as expected.

  • Like 1
Link to comment
1 hour ago, itimpi said:

Thought it was worth mentioning that the latest plugin update should now behave as you expected (at least it appears to in my testing).   

 

I have also added putting an entry in the syslog when a manual action is detected (although it my take a few minutes for the plugin to detect it) which should help make it clearer if something is happening that is not as expected.

Thanks for the heads up and update!

When you say behave as I expected do you mean with regards to how I thought the manual increments setting only used increments if the parity check had been manually paused?

 

Funnily enough I am doing a parity check right now because I had a power outage and I thought I would try do some testing. I'm on "Version: 2023.06.18" which I believe is the latest but I seem to get the standard behaviour.

 

I updated the increments to test in real time. Here is what I did:

 

START - 18:40, END - 18:45. Manual pause before start.

Spoiler
Jun 20 18:37:49 unraid kernel: mdcmd (41): nocheck pause
Jun 20 18:37:49 unraid kernel: md: recovery thread: exit status: -4
Jun 20 18:38:22 unraid ool www[14255]: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php 'updatecron'
Jun 20 18:40:01 unraid Parity Check Tuning: Resumed: Manual Correcting Parity-Check
Jun 20 18:40:01 unraid Parity Check Tuning: Send notification: Resumed: Manual Correcting Parity-Check (71.9% completed) 
Jun 20 18:40:01 unraid Parity Check Tuning: ... but suppressed as system notifications do not appear to be enabled
Jun 20 18:40:06 unraid kernel: mdcmd (42): check resume
Jun 20 18:40:06 unraid kernel: 
Jun 20 18:40:06 unraid kernel: md: recovery thread: check P ...
Jun 20 18:45:01 unraid Parity Check Tuning: Paused: Manual Correcting Parity-Check
Jun 20 18:45:07 unraid kernel: mdcmd (43): nocheck pause
Jun 20 18:45:07 unraid kernel: 
Jun 20 18:45:07 unraid kernel: md: recovery thread: exit status: -4
Jun 20 18:45:12 unraid Parity Check Tuning: Send notification: Paused: Manual Correcting Parity-Check (72.3% completed) 
Jun 20 18:45:12 unraid Parity Check Tuning: ... but suppressed as system notifications do not appear to be enabled

 

It behaved as expected and paused the parity check at the end of the increment.

 

START - 18:50, END - 18:55. Before increment start I manually resumed the parity check.

Spoiler
Jun 20 18:45:27 unraid ool www[6663]: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php 'updatecron'
Jun 20 18:45:35 unraid kernel: mdcmd (44): check resume
Jun 20 18:45:35 unraid kernel: md: recovery thread: check P ...
Jun 20 18:55:01 unraid Parity Check Tuning: Paused: Manual Correcting Parity-Check
Jun 20 18:55:07 unraid kernel: mdcmd (45): nocheck pause
Jun 20 18:55:07 unraid kernel: 
Jun 20 18:55:07 unraid kernel: md: recovery thread: exit status: -4
Jun 20 18:55:12 unraid Parity Check Tuning: Send notification: Paused: Manual Correcting Parity-Check (72.9% completed) 
Jun 20 18:55:12 unraid Parity Check Tuning: ... but suppressed as system notifications do not appear to be enabled

 

Parity check was already running due to manual resume so no start at 18:50 but it still automatically paused at 18: 55. 

 

I thought maybe that I wasn't leaving enough time between the resume and start of the next parity check increment so manually resumed and waited ~35mins until the next increment start.

START - 19:30, END - 19:35.

Spoiler
Jun 20 18:57:39 unraid kernel: mdcmd (46): check resume
Jun 20 18:57:39 unraid kernel: md: recovery thread: check P ...
Jun 20 19:28:44 unraid ool www[3931]: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php 'updatecron'
Jun 20 19:35:01 unraid Parity Check Tuning: Paused: Manual Correcting Parity-Check
Jun 20 19:35:06 unraid kernel: mdcmd (47): nocheck pause
Jun 20 19:35:06 unraid kernel: 
Jun 20 19:35:06 unraid kernel: md: recovery thread: exit status: -4
Jun 20 19:35:11 unraid Parity Check Tuning: Send notification: Paused: Manual Correcting Parity-Check (75.5% completed) 
Jun 20 19:35:11 unraid Parity Check Tuning: ... but suppressed as system notifications do not appear to be enabled

 

It still paused the parity check at the end.

 

This is no big issue obviously but just thought I would share my findings. I finally have a UPS now so hopefully I can do less of these hahaha!

Edited by Swarles
Link to comment

@Swarles

The behaviour you should now expect is:

  • No action will be taken for manual checks unless you have activated that option within the plugins setting.
  • If at the start time for the increment the check is paused then it will be resumed
  • If at the end time for the increment the check is running then it will be paused.
  • if you have enabled the options to pause if mover/ca backup are running or overheating then this happens independently of whether you have manually paused or resumed a check.  The only caveat is that if paused due to one of these conditions AND manual checks are set for increments AND one of them caused a pause within the increment period then no resume is issued if they end after the increment end time.

if you manually pause or resume a check then as long as the above conditions are not met then the plugin should take no action.

 

I THINK this is what you described as happening?   I also think it will meet most peoples needs as the expectation is that you will set increments to run in idle periods when there is probably nobody using the server or looking at the GUI, and manually issue pause or resumes outside this time if you want them.

Link to comment
5 minutes ago, itimpi said:

@Swarles

The behaviour you should now expect is:

  • No action will be taken for manual checks unless you have activated that option within the plugins setting.
  • If at the start time for the increment the check is paused then it will be resumed
  • If at the end time for the increment the check is running then it will be paused.
  • if you have enabled the options to pause if mover/ca backup are running or overheating then this happens independently of whether you have manually paused or resumed a check.  The only caveat is that if paused due to one of these conditions AND manual checks are set for increments AND one of them caused a pause within the increment period then no resume is issued if they end after the increment end time.

if you manually pause or resume a check then as long as the above conditions are not met then the plugin should take no action.

 

I THINK this is what you described as happening?   I also think it will meet most peoples needs as the expectation is that you will set increments to run in idle periods when there is probably nobody using the server or looking at the GUI, and manually issue pause or resumes outside this time if you want them.

Oh okay yep! This is my misunderstanding and in that case is definitely working as expected :)

Link to comment

Is this a bug or feature? 

Gist of my discrete post: I have my Parity Scheduler set to "Monthly" on the "31" at "01:00" am. With these settings, I am expecting a Parity Check to run every other month (months that have a 31st day) at 1am on the 31st. 

 

However, on my dashboard in the Parity Check section, it says my next scheduled check is for July 01st at 1am. 

 

Thoughts?

Link to comment
37 minutes ago, Shu said:

Is this a bug or feature? 

Gist of my discrete post: I have my Parity Scheduler set to "Monthly" on the "31" at "01:00" am. With these settings, I am expecting a Parity Check to run every other month (months that have a 31st day) at 1am on the 31st. 

 

However, on my dashboard in the Parity Check section, it says my next scheduled check is for July 01st at 1am. 

 

Thoughts?

 

That sounds like the built-in Parity Check scheduling feature - not the parity Check tuning settings?

Link to comment

I'm seeing some spam in my var/log/syslog:
 

Jun 22 11:37:18 Edge crond[4773]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 22 11:38:24 Edge crond[4773]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 22 11:39:24 Edge crond[4773]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 22 11:40:42 Edge crond[4773]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null



And this is from /var/log/phplog:
 

[22-Jun-2023 11:50:44 America/Denver] PHP Fatal error:  Uncaught Error: Undefined constant "parityTuningProgressSave" in /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php:217
Stack trace:
#0 {main}
  thrown in /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php on line 217


I can't seem to find where "parityTuningProgressSave" is defined in the php file mentioned - is this a bug?

Link to comment
14 hours ago, SpartanXXX said:

I'm seeing some spam in my var/log/syslog:
 

Jun 22 11:37:18 Edge crond[4773]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 22 11:38:24 Edge crond[4773]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 22 11:39:24 Edge crond[4773]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Jun 22 11:40:42 Edge crond[4773]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null



And this is from /var/log/phplog:
 

[22-Jun-2023 11:50:44 America/Denver] PHP Fatal error:  Uncaught Error: Undefined constant "parityTuningProgressSave" in /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php:217
Stack trace:
#0 {main}
  thrown in /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php on line 217


I can't seem to find where "parityTuningProgressSave" is defined in the php file mentioned - is this a bug?

Can you please confirm that you were trying to run something via the Parity Check Tuning Assistant?  That line is meant to be a call to sub-routine that can help with debugging issues and the subroutine is not being found.   Since it is only a debugging aid it was not necessarily showing up in functional testing, but still needs to be fixed.  If you can provide confirmation that you were using the Assistant then that will mean I can make and test the fix that needs doing.

Link to comment
3 hours ago, SpartanXXX said:

Yeah I can confirm that it was trying to do a Partiy Check and I do my automated checks in pieces with the Tuning Assistant

Thanks for the confirmation.   I will work on getting the fix out soon.

 

just for interest is there any reason you do it this way rather than simply setting up increments to automatically run the checks (probably in off hours) with no further manual involvement.  I had not really envisaged users using the Assistant in this way as automated increments seemed easier and less effort. 

Link to comment
6 minutes ago, SpartanXXX said:

I have a fairly irregular schedule and I need to use the same server for specific workloads when I'm home. So I end up not getting to totally be hands-off. That plus the recent upgrade to 6.12 was causing a little bit of a nightmare in terms of running into issues.

Ok.   I was a bit thrown off when you mentioned automated checks and the Assistant.   With the Assistant you are by definition manually running the check over a specified range.

 

At the moment I am not sure checks run by the assistant end up in the history in a sensible form.   Do you think there should be a configuration setting in the Assistant to have partial checks properly in the history and labelled as such with a correct exit status for that check?

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.