Warrentheo Posted September 28, 2018 Share Posted September 28, 2018 (edited) 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, 2018 by Warrentheo Quote Link to comment
eric.ruck Posted October 6, 2018 Share Posted October 6, 2018 (edited) 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, 2018 by eric.ruck Quote Link to comment
ClintE Posted October 27, 2018 Share Posted October 27, 2018 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... Quote Link to comment
XCVB Posted October 30, 2018 Share Posted October 30, 2018 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. Quote Link to comment
tjb_altf4 Posted October 30, 2018 Share Posted October 30, 2018 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/ Quote Link to comment
DerfMcDoogal Posted November 24, 2018 Share Posted November 24, 2018 Built up a new 6.6.5 and also have this problem. Quote Link to comment
bonienl Posted November 24, 2018 Share Posted November 24, 2018 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. Quote Link to comment
trurl Posted November 24, 2018 Share Posted November 24, 2018 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. Quote Link to comment
CarstenD Posted September 26, 2019 Share Posted September 26, 2019 (edited) 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, 2019 by CarstenD Quote Link to comment
bonienl Posted September 26, 2019 Share Posted September 26, 2019 Redo your parity schedule settings, so they get updated and corrected. Quote Link to comment
CarstenD Posted September 28, 2019 Share Posted September 28, 2019 @Bonienl: Thanks but tried it. Restarted a couple of times. It seems to have stopped, but I haven't changed anything...? Quote Link to comment
brankko Posted October 17, 2022 Share Posted October 17, 2022 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? Quote Link to comment
trurl Posted October 17, 2022 Share Posted October 17, 2022 Attach Diagnostics to your NEXT post in this thread Quote Link to comment
brankko Posted October 17, 2022 Share Posted October 17, 2022 Here it is. Attached tower-diagnostics-20221017-1403.zip Quote Link to comment
trurl Posted October 17, 2022 Share Posted October 17, 2022 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. Quote Link to comment
trurl Posted October 17, 2022 Share Posted October 17, 2022 What do you get from command line with this? crontab -l And this? cat /etc/cron.d/root Quote Link to comment
brankko Posted October 18, 2022 Share Posted October 18, 2022 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) Quote Link to comment
Frank1940 Posted October 18, 2022 Share Posted October 18, 2022 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. Quote Link to comment
brankko Posted October 18, 2022 Share Posted October 18, 2022 I made a manual restart, with stopped array and docker apps. What else could start an automatic parity check? Quote Link to comment
Frank1940 Posted October 18, 2022 Share Posted October 18, 2022 (edited) 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, 2022 by Frank1940 Quote Link to comment
brankko Posted October 18, 2022 Share Posted October 18, 2022 @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. Quote Link to comment
Recommended Posts
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.