Just fyi: I've updated to version: 2022.02.18. But this issue with the notification of resume/pause (Yes/No topic) still persists. 

I'm just mentioning it because I think it was addressed in the release notes of this version, if I remember right. 

I also completely reinstalled the plugin, same behaviour. My server runs on 6.9.2.

Just now, Tjareson said:

Just fyi: I've updated to version: 2022.02.18. But this issue with the notification of resume/pause (Yes/No topic) still persists. 

I'm just mentioning it because I think it was addressed in the release notes of this version, if I remember right. 

I also completely reinstalled the plugin, same behaviour. My server runs on 6.9.2.

I managed to recreate what I thought was your issue and correct it.   Sounds like there must be another edge case that I missed.

 

if it is possible to have the plugins testing Level of logging enabled and recreate the issue at your end and then let me have the syslog (or diagnostics which includes syslog) to give me more detail on the exact sequence of events that is occurring that may help with pinning it down.

8 minutes ago, itimpi said:

if it is possible to have the plugins testing Level of logging enabled 

Sure, can you let me know where I can do that? (I'm using unraid since a couple of days only)

19 minutes ago, Tjareson said:

Sure, can you let me know where I can do that? (I'm using unraid since a couple of days only)

If you go into the plugins settings (under Settings->Scheduler) there is an option to set the logging level.  The most verbose one is Testing.   The output of that is specifically designed to give the developer (me) lots of details of what is happening.   Under the Testing level you can choose whether the plugins log entries should be written to syslog (in RAM), the flash drive, or both.  I slightly prefer the output of the syslog option as it tells me more about anything else going on at the Unraid level, but the flash option is probably also sufficient.

 

Note that you do not want to leave that option enabled permanently as being very verbose it can end up filling up available log space. 
 

So I've switched on Testing log to syslog on 15:45:30, then I try to switch two times the resume/pause notification to yes and stopped Testing log to syslog precisely at 15:46:00

So syslog shows:
Feb 21 15:45:30 server01 ool www[23124]: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php 'updatecron'
Feb 21 15:45:30 server01 Parity Check Tuning: TESTING: setting locale from dynamix setting
Feb 21 15:45:30 server01 Parity Check Tuning: TESTING: Multi-Language support active, locale: 
Feb 21 15:45:30 server01 Parity Check Tuning: TESTING: ----------- UPDATECRON begin ------
Feb 21 15:45:30 server01 Parity Check Tuning: TESTING: Creating required cron entries
Feb 21 15:45:30 server01 Parity Check Tuning: TESTING: Deleted cron marker file 
Feb 21 15:45:30 server01 Parity Check Tuning: DEBUG:   Created cron entry for monitoring disk temperatures
Feb 21 15:45:30 server01 Parity Check Tuning: DEBUG:   updated cron settings are in /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron
Feb 21 15:45:30 server01 Parity Check Tuning: TESTING: ----------- UPDATECRON end ------
Feb 21 15:45:30 server01 Parity Check Tuning: TESTING: setting locale from dynamix setting
Feb 21 15:45:30 server01 Parity Check Tuning: TESTING: Multi-Language support active, locale: 
Feb 21 15:45:37 server01 ool www[22985]: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php 'updatecron'
Feb 21 15:45:37 server01 Parity Check Tuning: TESTING: setting locale from dynamix setting
Feb 21 15:45:37 server01 Parity Check Tuning: TESTING: Multi-Language support active, locale: 
Feb 21 15:45:37 server01 Parity Check Tuning: TESTING: ----------- UPDATECRON begin ------
Feb 21 15:45:37 server01 Parity Check Tuning: TESTING: Creating required cron entries
Feb 21 15:45:38 server01 Parity Check Tuning: TESTING: Deleted cron marker file 
Feb 21 15:45:38 server01 Parity Check Tuning: DEBUG:   Created cron entry for monitoring disk temperatures
Feb 21 15:45:38 server01 Parity Check Tuning: DEBUG:   updated cron settings are in /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron
Feb 21 15:45:38 server01 Parity Check Tuning: TESTING: ----------- UPDATECRON end ------
Feb 21 15:45:38 server01 Parity Check Tuning: TESTING: setting locale from dynamix setting
Feb 21 15:45:38 server01 Parity Check Tuning: TESTING: Multi-Language support active, locale: 
Feb 21 15:45:43 server01 ool www[24619]: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php 'updatecron'
Feb 21 15:45:43 server01 Parity Check Tuning: TESTING: setting locale from dynamix setting
Feb 21 15:45:43 server01 Parity Check Tuning: TESTING: Multi-Language support active, locale: 
Feb 21 15:45:43 server01 Parity Check Tuning: TESTING: ----------- UPDATECRON begin ------
Feb 21 15:45:43 server01 Parity Check Tuning: TESTING: Creating required cron entries
Feb 21 15:45:43 server01 Parity Check Tuning: TESTING: Deleted cron marker file 
Feb 21 15:45:43 server01 Parity Check Tuning: DEBUG:   Created cron entry for monitoring disk temperatures
Feb 21 15:45:43 server01 Parity Check Tuning: DEBUG:   updated cron settings are in /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron
Feb 21 15:45:43 server01 Parity Check Tuning: TESTING: ----------- UPDATECRON end ------
Feb 21 15:45:43 server01 Parity Check Tuning: TESTING: setting locale from dynamix setting
Feb 21 15:45:43 server01 Parity Check Tuning: TESTING: Multi-Language support active, locale: 
Feb 21 15:46:00 server01 ool www[24618]: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php 'updatecron'

 

Doesn't look very comprehensive to me - in case you need anything else, let me know. 

On 2/20/2022 at 5:18 PM, itimpi said:

The whole idea of the new option is that it does not matter if they start at the same time.   If the option is enabled (the default is Yes) then the plugins parity check code is continually monitoring whether mover is running and if it finds it is it will apply the pause, and then automatically resume when mover completes (assuming the server is still within the time slot for running a parity check increment).

 

Finally got my sheduled parity check , so from syslog mover strted in 0:00:01 

(

Mar  1 00:00:01 xxxxx root: Starting Mover
Mar  1 00:00:01 xxxxx root: Forcing turbo write on
Mar  1 00:00:01 xxxxx kernel: mdcmd (41): set md_write_method 1

....

Mar  1 00:05:04 xxxxx root: mover: finished
Mar  1 00:05:04 xxxxx root: mvlogger: No After Script to Run.
Mar  1 00:05:04 xxxxx root: Restoring original turbo write mode
Mar  1 00:05:04 xxxxx kernel: mdcmd (43): set md_write_method auto
Mar  1 00:05:04 xxxxx kernel: 
)

 

but i didnt saw by unraid gui that parity was paused and wait for mover finished also i cant find it log ,only when parity started i think 0:00:06...

I checked the syslog and :

 

Edited March 1, 20224 yr by Masterwishx

I would need the Testing mode of logging in the plugin running during the period to see if I can work out what might be the problem.

 

Have you rebooted since updating the plugin to the latest version?   Just want to make sure you have the latest version.

22 minutes ago, itimpi said:

Have you rebooted since updating the plugin to the latest version?   Just want to make sure you have the latest version.

 

i turn off server every night .

also have auto update enabled twice in day,  this ver 2022.02.18

i will change to test mode and will try check parity again in this week ...

 

7 minutes ago, Masterwishx said:

 

i turn off server every night .

also have auto update enabled twice in day,  this ver 2022.02.18

i will change to test mode and will try check parity again in this week ...

 

There can be a short period while a parity check and mover are both running until the parity check background monitoring task kicks in.   I could see this explaining why the initial small files did not trigger the pause, but it looks like you then had a big file being moved which the monitor task SHOULD have picked up.

 

you might want to check in the plugin settings that the option to pause if mover is running is enabled.

22 minutes ago, itimpi said:

you might want to check in the plugin settings that the option to pause if mover is running is enabled.

 

i have it enabled ,i think its by default enabled .

also i have set in mover not to run when parity running and by syslog mover not started at 6:00 becose was parity running ...

 

 

 

OK - just thought I should check.  Getting the right level of testing logging will tell me what is happening under the covers.

Hello,

 

I have a parity check running for the first time since I've installed this plugin and i got this error message when I'm going to the plugin Tools 'Parity Problems Assistant' page <unraid_server>/Tools/Parity.check.problems

Quote

Fatal error: Uncaught Error: Call to undefined function isArrayOperationActive() in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(518) : eval()'d code:35 Stack trace: #0 /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(518): eval() #1 /usr/local/emhttp/plugins/dynamix/template.php(71): require_once('/usr/local/emht...') #2 {main} thrown in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(518) : eval()'d code on line 35

 

Can't get more information for now, nothing visible in the classic unraid log. The parity seems to run properly.

My plugin version is 2022.02.18 and Unraid is 6.9.2

Edited March 7, 20224 yr by JeanR

First time I have heard of anyone reporting trying to use that feature   I can reproduce that error message so will get it fixed.   I must have made a code reorganisation internally in the plugin and got something wrong and did not retest the Assistant.

 

The Assistant is independent of the handling of pause/resume of the parity check so that should not be affected.

Well it's mainly because i saw some strange behavior with the parity start date ("09AM" instead of the expected "02AM") this morning. But with a global progress % much more advanced for something who have allegedly started 10min ago...

 

The log also had new lines never seen before like "tower kernel: md: recovery thread: check P ..."

 

Then i remember installing this plugin week ago, wanted to look at its configuration and tadaaam

 

Anyway, thank for the quick answer and the plugin!

Edited March 7, 20224 yr by JeanR

53 minutes ago, JeanR said:

The log also had new lines never seen before like "tower kernel: md: recovery thread: check P

That has always been there when a parity check started  

Just thought it was worth mentioning that I am looking into the best way to integrate this plugin's settings and capabilities with the new facility built into the just released 6.10.0-rc3 for running parity checks in increments.  

 

The easiest for me (and a short term solution for existing users) is to NOT use the new built-in feature for increments and let this plugin continue to handle running the increments.  This will allow all the plugin functionality to run unaffected by the move to rc3 (or later).  I will shortly make a release that I have validated runs correctly with rc3 with all the plugin functionality intact it you are taking this approach

 

Longer term I want to retain any functionality this plugin has that goes beyond the built in functionality while avoiding duplicating anything unnecessarily.  Before I make any final decisions I am going to have to work out exactly how rc3 handles manual and automatic checks as well as scheduled ones to see if the plugin settings relating to these are still relevant.  I also need to see if the new functionality also covers (or interacts with) other operations the plugin handles like rebuilds and clear operations; restarting parity checks after an array restart; temperature related pause/resume; etc.  This work is likely to take some time to complete.

 

 

I've started seeing parity tuning errors in syslog. 

 

Mar 21 06:40:20 tdm root: RTNETLINK answers: File exists
Mar 21 06:40:20 tdm Parity Check Tuning: PHP error_reporting() set to E_ERROR|E_WARNING|E_PARSE|E_CORE_ERROR|E_CORE_WARNING|E_COMPILE_ERROR|E_COMPILE_WARNING|E_USER_ERROR|E_USER_WARNING|E_USER_NOTICE|E_STRICT|E_RECOVERABLE_ERROR|E_USER_DEPRECATED
Mar 21 06:40:20 tdm emhttpd: nothing to sync
Mar 21 06:40:20 tdm sudo:     root : PWD=/ ; USER=root ; COMMAND=/bin/bash -c /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '/boot/config/ssl/certs' -showups
Mar 21 06:40:20 tdm sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Mar 21 06:40:20 tdm Parity Check Tuning: PHP error_reporting() set to E_ERROR|E_WARNING|E_PARSE|E_CORE_ERROR|E_CORE_WARNING|E_COMPILE_ERROR|E_COMPILE_WARNING|E_USER_ERROR|E_USER_WARNING|E_USER_NOTICE|E_STRICT|E_RECOVERABLE_ERROR|E_USER_DEPRECATED
Mar 21 06:40:21 tdm kernel: eth0: renamed from veth505b9c4

 

They are fairly regular throughout syslog.  Noticed them today while running RC3, still there after RC4

That looks benign - I probably have just used the wrong level of logging on the message that gives the PHP level of error reporting and that message should be set to only occur at the “testing’ log level. I will get it rectified.

 

I have just noticed that the setting for reporting notifications on temperature related issues is not being displayed correctly in the settings so a fix for that needs issuing.

 

9 hours ago, dalben said:

I've started seeing parity tuning errors in syslog. 

 

Mar 21 06:40:20 tdm root: RTNETLINK answers: File exists
Mar 21 06:40:20 tdm Parity Check Tuning: PHP error_reporting() set to E_ERROR|E_WARNING|E_PARSE|E_CORE_ERROR|E_CORE_WARNING|E_COMPILE_ERROR|E_COMPILE_WARNING|E_USER_ERROR|E_USER_WARNING|E_USER_NOTICE|E_STRICT|E_RECOVERABLE_ERROR|E_USER_DEPRECATED
Mar 21 06:40:20 tdm emhttpd: nothing to sync
Mar 21 06:40:20 tdm sudo:     root : PWD=/ ; USER=root ; COMMAND=/bin/bash -c /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '/boot/config/ssl/certs' -showups
Mar 21 06:40:20 tdm sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Mar 21 06:40:20 tdm Parity Check Tuning: PHP error_reporting() set to E_ERROR|E_WARNING|E_PARSE|E_CORE_ERROR|E_CORE_WARNING|E_COMPILE_ERROR|E_COMPILE_WARNING|E_USER_ERROR|E_USER_WARNING|E_USER_NOTICE|E_STRICT|E_RECOVERABLE_ERROR|E_USER_DEPRECATED
Mar 21 06:40:21 tdm kernel: eth0: renamed from veth505b9c4

 

They are fairly regular throughout syslog.  Noticed them today while running RC3, still there after RC4

i get the same errors in the log.  running UNRAID  6.10.0 RC2

Edited March 21, 20224 yr by LOOPMDS
typo

2 hours ago, LOOPMDS said:

i get the same errors in the log.  running UNRAID  6.10.0 RC2

It is not actually an error   It is an information message that was only intended to be output when logging level is set to Testing

also having this in log: 

Mar 21 18:00:04 Server Parity Check Tuning: PHP error_reporting() set to E_ERROR|E_WARNING|E_PARSE|E_CORE_ERROR|E_CORE_WARNING|E_COMPILE_ERROR|E_COMPILE_WARNING|E_USER_ERROR|E_USER_WARNING|E_USER_NOTICE|E_STRICT|E_RECOVERABLE_ERROR|E_USER_DEPRECATED

 

but i have basic log set , it was in test log when ckecked the problem posted befor but now i have basic log ....

 

Edited March 25, 20224 yr by Masterwishx

1 minute ago, Masterwishx said:

also having this in log: 

Mar 21 18:00:04 DaRKNaS Parity Check Tuning: PHP error_reporting() set to E_ERROR|E_WARNING|E_PARSE|E_CORE_ERROR|E_CORE_WARNING|E_COMPILE_ERROR|E_COMPILE_WARNING|E_USER_ERROR|E_USER_WARNING|E_USER_NOTICE|E_STRICT|E_RECOVERABLE_ERROR|E_USER_DEPRECATED

 

but i have basic log set , it was in test log when ckecked the problem posted befor but now i have basic log ....

 

This is what I mentioned previously.   I only intended that message (which is informative and not an error) to happen if the Testing level of logging was actIve, but in the release made yesterday it is happening at all log levels.

41 minutes ago, itimpi said:

but in the release made yesterday it is happening at all log levels.

 

Oh ,sorry for my missunderstanding...

 

Also i wanted to tell that i checked the problem we talked befor about starting parity and mover checking at 0:00 ,

and from what i can understand from log the parity is yes paused and after mover ended is continued but i dont remember that i saw pause of parity in unraid webGui in left botton corner .... please tell me if im right and if i should see pause in gui?

 

Edited March 21, 20224 yr by Masterwishx

11 minutes ago, Masterwishx said:

but i dont remember that i saw pause of parity in unraid webGui in left botton corner .... please tell me if im right and if i should see pause in gui?

If a pause happens this should definitely show in the GUI with '(Paused)' appended to the operation in the status line.  Note that this text is done at the core UnraId level and is not added by the plugin so happens even when the plugin is not installed

 

11 minutes ago, itimpi said:

If a pause happens this should definitely show in the GUI with '(Paused)'

 

i think it was pause but if you can check the log and tell if it ,but its not big problem i can make run parity at 0:30 after mover 0:00..

i posted becose we talked befor...