6.6.0 - 6.6.5 - Parity Check runs every day, set to only on Sunday

11 minutes ago, Startide said:

Currently running on 6.6.5 but this has been going on since the initial release of 6.6.x, it did not happen on the previous versions. I have my Parity check scheduled to run at 12:30am Sunday, once a week. Unfortunately it runs every single day. Typically takes about 10.5 hours so the server is pretty slow while it is running.

 

Activity started on Mon 12 Nov 2018 12:30:01 AM MST (today), finding 0 errors.
Last result: 10 hours, 39 minutes, 34 seconds. Average speed: 104.3 MB/s

 

Sample from the parity-check.log

2018 Oct 19 10:40:08|38407|104.2 MB/s|0|0
2018 Oct 20 10:39:36|38375|104.3 MB/s|0|0
2018 Oct 21 10:41:08|38467|104.0 MB/s|0|0
2018 Oct 22 10:39:47|38386|104.2 MB/s|0|0
2018 Oct 23 08:40:18|31217|Unavailable|-4|0
2018 Oct 24 11:58:23|41302|96.9 MB/s|0|0
2018 Oct 25 11:13:32|38611|103.6 MB/s|0|0
2018 Nov  1 12:39:17|43756|91.4 MB/s|0|0
2018 Nov  2 12:48:33|44312|90.3 MB/s|0|0
2018 Nov  3 12:28:36|43115|92.8 MB/s|0|0
2018 Nov  4 11:00:43|41442|96.5 MB/s|0|0
2018 Nov  5 12:10:18|42017|95.2 MB/s|0|0
2018 Nov  6 12:07:48|41867|95.6 MB/s|0|0
2018 Nov  7 10:16:49|35208|Unavailable|-4|0
1969 Dec 31 17:00:00|0|nan B/s||
2018 Nov 10 11:10:08|38407|104.2 MB/s|0|0
2018 Nov 11 11:09:35|38374|104.3 MB/s|0|0

 

The times you see gaps is when I have turned off the check in frustration, no idea what the Dec 31 one is all about.

 

Current check (going on right now):

 

Total size:4 TB

Elapsed time:9 hours, 21 minutes

Current position:3.59 TB (89.7 %)

Estimated speed:92.5 MB/sec

Estimated finish:1 hour, 14 minutes

Sync errors corrected:0

 

Anyone have any ideas on what I can check in order to figure this out? It never says it has to write corrections, so I don't know if something hardware wise is causing it to kick off (you would think it would be telling me if that was the issue).

 

I have attached the diagnostics, screenshot of the scheduler. If anything else is needed, I can upload that also.

 

 

 

jupiter-diagnostics-20181112-0948.zip

Confirmed.  Those settings result in a cron of

# Generated parity check schedule:
30 0 * * * /usr/local/sbin/mdcmd check  &> /dev/null || :

For the time being you can run the check on any day other than sunday and it will work properly.

So I just happened to choose the one day that resulted in a bug? lol Just my luck.

 

Didn't even think to check the actual crontab file.

 

# Generated parity check schedule:
30 0 * * * /usr/local/sbin/mdcmd check  &> /dev/null || :

 

I changed it to Saturday and it is correct.

 

# Generated parity check schedule:
30 0 * * 6 /usr/local/sbin/mdcmd check  &> /dev/null || :

 

So it should read (if I remember my cron entries):

 

30 0 * * 0 /usr/local/sbin/mdcmd check  &> /dev/null || :

 

0 = Sunday, * = All

 

Thank you for the sanity check.

 

 

 

 

 

Turns out this is a duplicate:

Guess bug was not completely stamped out..