Scheduled Parity Check did not run

Are you on latest releases? v6.6.6? If not upgrade.

As an additional step/test. Re-apply the settings.

Yes, I'm on 6.6.6.

 

My first thought was "calendar week" vs. "week of year" but both is at #1.

 

Will try again with Friday in first week 23:00 tonight. Will see what happens.

 

"First week" means a date between 1 and 7. Combined with the day "Thursday" this translates to Thursday, 3rd of January.

 

If you change the day to Friday, it should run on Friday, 4th of January.

This is not a bug correct?

9 minutes ago, limetech said:

This is not a bug correct?

For me it works as designed.

Changed Status to Closed

Changed Priority to Other

On 1/8/2019 at 2:05 PM, bonienl said:

For me it works as designed.

TLDR:

 

@bonienl,   issue here is that cron on slackware/unRaid doesn't seem to support ranges (and seems to not be  consistent in that not every field allows comma separated values either).  Revert the simplification commit on Sept 8 (https://github.com/limetech/webgui/commit/d07fec0c6ff594783ef0eff1544d3299e57ff7d6#diff-c74d37c40da2052f6f1e7778412b87db) and everything will work fine.

 

@limetech, this is a bug even though the cron entry appears to be correct.

 

 

Just happened to have noticed that mine never ran either (on both my servers)

 

While I can't 100% guarantee that both servers wasn't being reset or something when the last parity check was scheduled to happen, it never ran.  Just to test, I've changed it to 2nd week

# Generated parity check schedule:
0 22 8-14 * 5 /usr/local/sbin/mdcmd check  &> /dev/null || :

an 11 21:55:01 ServerA emhttpd: req (11): csrf_token=****************&title=System+Log&cmd=%2FwebGui%2Fscripts%2Ftail_log&arg1=syslog
Jan 11 21:55:01 ServerA emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog
Jan 11 21:55:01 ServerA crond[1659]: exit status 127 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null
Jan 11 21:55:20 ServerA root: plugin: running: anonymous
Jan 11 21:59:51 ServerA emhttpd: req (12): csrf_token=****************&title=System+Log&cmd=%2FwebGui%2Fscripts%2Ftail_log&arg1=syslog
Jan 11 21:59:51 ServerA emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog
Jan 11 22:00:02 ServerA root: Cache used space threshhold (70) not exceeded.  Used Space: 38.  Not moving files
Jan 11 22:00:42 ServerA kernel: CIFS VFS: Close unmatched open
Jan 11 22:01:06 ServerA kernel: mdcmd (62): spindown 0
Jan 11 22:01:07 ServerA kernel: mdcmd (63): spindown 1

So you can see that it never actually ran.

 

if I however change the cron tab back to the original method you were using to run in the first / second / third / fourth week, it does work fine.

 

# Generated parity check schedule:
15 22 * * 5 [[ $(date +%e -d -7days) -le 7 ]] && /usr/local/sbin/mdcmd check  &> /dev/null || :

Jan 11 22:15:01 ServerA kernel: mdcmd (64): check 
Jan 11 22:15:01 ServerA kernel: md: recovery thread: check P ...
Jan 11 22:15:02 ServerA kernel: md: using 8192k window, over a total of 3907018532 blocks.

 

Edited January 12, 2019 by Squid

Should be fixed next release of unRaid