Jump to content

[Bug] Parity check runs everyday when set to run weekly or monthly...


Warrentheo

Recommended Posts

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 by Warrentheo
Link to comment
  • 2 weeks later...

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 by eric.ruck
Link to comment
  • 3 weeks later...
  • 4 weeks later...
  • 10 months later...
  • 3 years later...

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?

Link to comment

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)

Screenshot 2022-10-18 at 10.52.43.png

Link to comment

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.

Link to comment
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:

image.png.fda3aab765eea75cffa3d7d4cb7fe2fc.png

 

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 by Frank1940
Link to comment

@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.

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.

×
×
  • Create New...