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.
This makes sense for computers not in home environments.
James Wilkinson wrote:
> 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 true, James, but my backup script, which I simply drop into /etc/cron.daily IS affected. I just let it run along with the other system jobs and all used to be fine. I had the whole shitload set to run at 10 minutes past the hour and after it was done, I could turn off my computer. Now, I have to either let the computer run for up to 68 minutes, just to guarantee that the jobs even start, let alone finish. I feel the best option to reintroduce full error-free functionality is to disable the delay script.
kwhiskerz{
Stay up-to-date with your friends through the Windows LiveT Spaces friends list. Check it out!
