My system currently seems to ignore the currently scheduler settings for Parity check, and runs more frequently than set... Currently it is set with the following settings under Settings-->Scheduler:

PARITY CHECK
Scheduled parity check: Weekly

Day of the week: Sunday

Day of the month: {------------}

Time of the day: 23:00

Month of the year: {------------}

Write corrections to parity disk: Yes

 

However, it has run every day for the last three days, and currently has this info on the main Dashboard page:

PARITY STATUS
Parity is valid
Last check incomplete on Fri 28 Sep 2018 08:47:20 AM CDT (today), finding 0 errors.
Error code: aborted	

Next check scheduled on Sun 30 Sep 2018 11:00:00 PM CDT
 Due in: 2 days, 13 hours, 13 minutes

This shows that it is scheduled for the currently correct settings, and gives the correct time for the next one to be due...

 

I have been running with this issue for a while since it is just a minor annoyance when discovered, however the latest versions of UnRaid didn't seem to fix it, and changing the settings repeatedly with the WebGui doesn't seem to affect the issue, though it will always show the correct time on the dashboard for when it is due...

 

Just updated to 6.6.1 this morning, was running 6.6.0 when the latest check tried to run last night...

Edited September 28, 20187 yr by Warrentheo

Im having same issue, Started on Oct 1, the day I upgraded to 6.6.1  Scheduled to run every 90 days, but since the 1st runs at 11:39 everyday.  Have reset the schedule now for Yearly, and rebooted. Will see what happens tomorrow.

 

Update: As posted above in original, as long as I do not use a WEEKLY or MONTHLY setting it runs as scheduled, if one of these is selected it runs everyday at 11:39

Edited October 8, 20187 yr by eric.ruck

I'm having the same issue, set parity schedule to run once a week and runs at the proper time scheduled, but every day.

 

Doing it manually right now...

Same here for me. I have it set to run every 60 days. It's running every 2 days instead. Something with the cron job seems messed up.

I think it's on the GUI end or something in the middle, I have not touched my scheduler in over a year and it's still working as expected.

Will be worth upgrading to 6.6.3 in case the bug has already been caught and fixed.

 

Best to repost to the bug forum so it gets traction: https://forums.unraid.net/bug-reports/stable-releases/

 

Built up a new 6.6.5 and also have this problem.

1 hour ago, DerfMcDoogal said:

Built up a new 6.6.5 and also have this problem.

Known issue, is corrected in the next release.

3 hours ago, DerfMcDoogal said:

Built up a new 6.6.5 and also have this problem.

If I remember correctly this is a bug parsing crontab if you have your schedule set for Sunday. You might try changing that until the fix is released.

I'm on 6.7.2. Set to last day of month, but it keeps running parity check every morning (?)
Is it because I'm filling it up with old stuff?

Edited September 26, 20196 yr by CarstenD

Redo your parity schedule settings, so they get updated and corrected.

@Bonienl: Thanks but tried it. Restarted a couple of times. It seems to have stopped, but I haven't changed anything...?

I'm using version: 6.11.1 and the same issue happening to me too.

At the moment Scheduled parity check is completely disabled, but it runs every day anyways.

I have tried to set it to weekly and that setting is completely ignored. It runs every day.

 

After reading this thread, I set it to custom date(s) so I can check if that is gonna be applied, but it seems that it's not fully resolved.

Or am I missing something?

Attach Diagnostics to your NEXT post in this thread 

Here it is. Attached

tower-diagnostics-20221017-1403.zip

Have you tried this?

On 9/26/2019 at 12:17 PM, bonienl said:

Redo your parity schedule settings, so they get updated and corrected.

 

What do you get from command line with this?

crontab -l

And this?

cat /etc/cron.d/root

 

 

Yes, the first thing I tried is to redo the settings.

 

root@Tower:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

 

and

 

root@Tower:~# cat /etc/cron.d/root
# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
40 3 * * * /usr/local/sbin/mover &> /dev/null

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

# CRON for CA background scanning of applications
44 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

 

And here is what I set up in the web ui (screenshot attached)

Are you aware that your server (re)started yesterday?  (This is the first line in your syslog.)

 

Oct 17 13:41:44 Tower kernel: Linux version 5.19.14-Unraid (root@Develop) (gcc (GCC) 12.2.0, GNU ld version 2.39-slack151) #1 SMP PREEMPT_DYNAMIC Thu Oct 6 09:15:00 PDT 2022

 

IF this occurred without your knowledge,  your server could have shutdown improperly before this  restart and that would initiate an automatic parity check.

I made a manual restart, with stopped array and docker apps.

 

What else could start an automatic parity check?

1 hour ago, brankko said:

I made a manual restart, with stopped array and docker apps.

 

What else could start an automatic parity check?

 

What causes an automatic parity check on  any reboot is the presence of the forcesync file in the /config folder on the flash/boot drive.  (This file is created when the array starts and is deleted when the array stops.)

 

Besides the cron jobs, I am not aware of anything else which will trigger a parity check.  The only other thing would be a malicious user or hacker.

 

I look at your output of the   cat /etc/cron.d/root   command and I notice that there appears to be too many parameters in the time/date setting table:

 

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

 

 

Look at this article for what I mean:

      https://www.cyberciti.biz/faq/how-do-i-add-jobs-to-cron-under-linux-or-unix-oses/

 

You may have found a bug!

 

This is what my setup looks like for the monthly parity check on my Testbed server:

 

This provides a monthly parity check that runs on the second day of the month (that day was my choice) rather than the first Sunday.  (Yes, I realize that Sunday could be a more convenient day...)  But it does work!

 

One more thing, it is recommended that the periodic parity check to be a non-correcting one.  It is not expected that this check will find an error.  If it ever should find one, you want to check things out to see if there is a hardware issue that should be addressed.   It may well be that a correcting parity rebuild may be required but the delay will allow you time to make that determination.

 

Edited October 18, 20223 yr by Frank1940

@Frank1940 Thanks! This is helpful.

 

I am currently evaluating trial version so I made a lot of exploration changes in my system to figure out how it works and how it would fulfil my needs. That was the reason I restarted my home server frequently. Definitely would do a clean install when I decide to go with full version.