cron problem

[James Wilkinson]

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 at redhat.com> 1.10-11
   - rebuilt
   - Resolves: rhbz#223472

   * Wed Oct 11 2006 Marcela Maslanova <mmaslano at redhat.com> 1.10-9
   - patch (#110894) for delaying more emails in the moment

   * Fri Jul 14 2006 Jesse Keating <jkeating at redhat.com> 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