kwhiskerz wrote: > On the weekend an update to cron came out with this new script: > /etc/cron.daily/000-delay.cronWhat it appears to do is to introduce a > random length of delay before cron/anacron run.What is the point of > introducing randomness into a finely tuned system? > > When one sets up crontab/anacrontab to go off at precisely a certain > time, one expects it to run at the time specified, and not at some > random time in the next 68 minutes!What purpose does this serve? Javier replied: > Oftentimes, Cron is used to setup communication with other servers to > update Clamav or Spamassassin, maybe to run Yum check-update. The > issue is that if everybody is hitting the servers on the hour, we have > instataneous hourly DOS attacks on those servers. The random delay > prevents this by randomizing the access time while guaranteeing that > within the next XX minutes you will run the update. kwhiskerz top-posted: > Thanks, makes sense.However, on my home computer, it is more vital > that jobs are run when I say they should be run, and not according to > a random formula. If the football game starts at 1630, I don't care to > be reminded up to 68 minutes afterward :-)I guess there's no harm in > removing that 000-delay.cron job, eh? Firstly, the 000-delay.cron job should only delay the jobs that are run from /etc/cron.daily (or /etc/cron.weekly, when a bug is fixed). Jobs in these directories are run *sequentially* (one after the other) so a long delay in 000-delay.cron will delay the rest of them. Jobs (e.g. those reminding you of football matches) that run directly from a crontab won't be affected. You can easily have lots of programs being run at the same time from the same crontab file -- one of them being run-parts /etc/cron.daily, which is waiting for 000-delay.cron to finish. But cron won't be waiting, and will still run its other jobs on time! (This is *highly* important on large servers with lots of processors, memory and disk bandwidth. It's common to kick off several long-running jobs from cron to run out of hours, and absolutely essential that this doesn't delay the system backup.) In fact, you couldn't predict when most jobs in /etc/cron.daily would run anyway, even on a server that's up all the time. This is because you can't be sure how long the previous jobs in that directory will take to run. Secondly, $ rpm -qf /etc/cron.daily/000-delay.cron crontabs-1.10-11.fc6.noarch tells you that the package responsible is called crontabs, and $ rpm -q --changelog crontabs | head * Wed Jan 24 2007 Marcela Maslanova <mmaslano@xxxxxxxxxx> 1.10-11 - rebuilt - Resolves: rhbz#223472 * Wed Oct 11 2006 Marcela Maslanova <mmaslano@xxxxxxxxxx> 1.10-9 - patch (#110894) for delaying more emails in the moment * Fri Jul 14 2006 Jesse Keating <jkeating@xxxxxxxxxx> 0 1.10-8 - rebuilt points you to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=110894 , which explains the reasoning for the change. Thirdly, the bug I mentioned is that the cron.weekly directory has an incorrect symlink, which is fairly easily tracked down as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224687 . The last comment in it is Fixed in rawhide, update soon. So you're going to get a new version of the package soon, which will replace the file. Hope this helps, James. -- E-mail: james@ | Top Tip: If you are being chased by a police dog, don't aprilcottage.co.uk | try to get away by crawling through a tunnel, going onto | a little see-saw, and jumping through a hoop of fire. | They are trained for that, you see. | -- "Bystander", London magistrate
