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{
_________________________________________________________________
Get connected - Use your Hotmail address to sign into Windows Live Messenger now.
http://get.live.com/messenger/overview