January 1, 201511 yr Just realized that the monthly parity check did not run today AND I am not getting my daily 6AM server status emails... all since updating to B12. I do get emails for the "cron for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null" stuff (already reported) and each reboot I get one from SNAP so SMTP settings are valid. As an aside, its lucky it didn't run this morning. I lost power for several hours so it would have been interrupted anyway
January 1, 201511 yr Same here actually Settings are Monthly First day 11am Write corrections No Though now that I think about it my server 'may' have been asleep at the time, not sure what it would've woken up new years day
January 1, 201511 yr Mine ran perfectly fine. What settings do you have? "Last checked on Thu 01 Jan 2015 03:55:57 PM EST (today), finding 0 errors. ? Duration: 12 hours, 55 minutes, 56 seconds. Average speed: 85.9 MB/sec"
January 2, 201511 yr Mine didn't either. I figured it was just a fluke for some reason and reloaded the settings and ran it manually. Was going to wait til February to file a defect report. And absolutely nothing in the syslog from the time it was supposed to have started.
January 2, 201511 yr Can those of you that didn't have a monthly parity check include the output of the following shell command? cat /var/spool/cron/crontabs/root In my case I can see the parity command is indeed scheduled, however I recently changed it from Weekly to Monthly, so maybe that's why mine was scheduled. # Scheduled Parity Check 0 3 1 * * /root/mdcmd check NOCORRECT 1>/dev/null 2>&1
January 2, 201511 yr Author Can those of you that didn't have a monthly parity check include the output of the following shell command? Tower login: root Password: Linux 3.17.4-unRAID. root@Tower:~# cat /var/spool/cron/crontabs/root # 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 # System data collection - poll every minute */1 * * * * /usr/lib/sa/sa1 1 1 & 1>/dev/null 2>&1 # Scheduled Parity Check 30 0 1 * * /root/mdcmd check 1>/dev/null 2>&1 root@Tower:~#
January 2, 201511 yr It actually looks like its not adding the cron job through a reboot. After I noticed that it didn't ran, I went back into settings, mucked around and ran one manually. Checking the cron job list it was there. So, I just proceeded to reboot to see if it survived, and now its gone (settings still state to do it monthly) Before the reboot: login as: root [email protected]'s password: Last login: Thu Jan 1 12:02:32 2015 from iona Linux 3.17.4-unRAID. root@Server_A:/etc/cron.monthly# cat /var/spool/cron/crontabs/root # 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 # System data collection - poll every minute */1 * * * * /usr/lib/sa/sa1 1 1 & 1>/dev/null 2>&1 # Scheduled Parity Check 0 0 1 * * /root/mdcmd check 1>/dev/null 2>&1 root@Server_A:/etc/cron.monthly# After the reboot: Broadcast message from root@Server_A (Thu Jan 1 20:30:17 2015): The system is going down for reboot NOW! login as: root [email protected]'s password: Linux 3.17.4-unRAID. root@Server_A:~# cat /var/spool/cron/crontabs/root # 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 # System data collection - poll every minute */1 * * * * /usr/lib/sa/sa1 1 1 & 1>/dev/null 2>&1 root@Server_A:~# And my flash drive IS writeable
January 2, 201511 yr It actually looks like its not adding the cron job through a reboot. After I noticed that it didn't ran, I went back into settings, mucked around and ran one manually. Checking the cron job list it was there. So, I just proceeded to reboot to see if it survived, and now its gone (settings still state to do it monthly) Same here, the cron entry does not survive a reboot
January 2, 201511 yr It actually looks like its not adding the cron job through a reboot. After I noticed that it didn't ran, I went back into settings, mucked around and ran one manually. Checking the cron job list it was there. So, I just proceeded to reboot to see if it survived, and now its gone (settings still state to do it monthly) Same here, the cron entry does not survive a reboot Yup, mine does not survive a reboot either.
January 2, 201511 yr I am going to go ahead and say I had this same issue. I didn't dig into cron yet, but what I discovered on 01/01/15 when I woke to find that my parity check (set for 3:30 am on the last day of the month) did not happen.. when I checked the scheduled events tab I noticed that it wasn't active... at first I thougth this was user error, but now I wonder if this was a product of writes to cron not suriving reboot. Also I've not recieved any emails since getting the test email, even with a couple of reboots. Is this expected?
January 2, 201511 yr I had mine disabled because I was moving some shares around. However, after turning it back on and then later rebooting I found it was not in cron even though it was enabled in the webGUI and in the file the webGUI maintains for this. So it does look like it is not being put in cron during boot.
January 2, 201511 yr The parity check did not run on my server either. I did observe on the Scheduler page that the Status is flagged as 'Stopped'! See attached screen capture for details.
January 20, 201511 yr The parity check did not run on my server either. I did observe on the Scheduler page that the Status is flagged as 'Stopped'! See attached screen capture for details. With so many folks reporting this, clearly there is an issue. We will investigate. Stay tuned.
October 3, 20169 yr Was there any resolution to this issue? I upgraded from 5.05 to 6.2 and noticed that my monthly parity check didn't run on the 1st of the month. I tried to upgrade using the automated plugin but it wouldn't boot after so I copied the syslinux folder over from the latest zip and ran make_bootable.bat I've tried disabling and re-enabling both notification and the monthly parity check in Scheduler but the cron job doesn't appear. I noticed when I disable the scheduled monthly parity check and re-enable the following message appears briefly at the bottom of the Scheduler page Warning: unlink(/tmp/memory.tmp): No such file or redirectory in /usr/local/emhttp/plugins/dynamix/include/update.parity.php on line 55 Don't know if it related, but I'm also unable to schedule a twice-weekly backup to an external hdd connected using the Unassigned Devices plugin
October 3, 20169 yr Was there any resolution to this issue? I upgraded from 5.05 to 6.2 and noticed that my monthly parity check didn't run on the 1st of the month. I tried to upgrade using the automated plugin but it wouldn't boot after so I copied the syslinux folder over from the latest zip and ran make_bootable.bat I've tried disabling and re-enabling both notification and the monthly parity check in Scheduler but the cron job doesn't appear. I noticed when I disable the scheduled monthly parity check and re-enable the following message appears briefly at the bottom of the Scheduler page Warning: unlink(/tmp/memory.tmp): No such file or redirectory in /usr/local/emhttp/plugins/dynamix/include/update.parity.php on line 55 Don't know if it related, but I'm also unable to schedule a twice-weekly backup to an external hdd connected using the Unassigned Devices plugin This one has long been fixed. Please post again in General Support for v6.
Archived
This topic is now archived and is closed to further replies.