Another alternative in bash :
#!/bin/bash
# randomize /etc/crontab
test -f /var/backups/crontab-orig || cp /etc/crontab /var/backups/crontab-orig
SUM=`sum -s /etc/hostname | cut -d -f1`
H=$[ 6 - ( $RANDOM % 2 ) ]
M=`printf %02d $[ ( $SUM ) % 60 ] `
sed -i -e s/^[0-9]*\(.*cron\.hourly.*\)/$M\1/
# One-liner
perl -p -i -e 'if(/run-parts/) { s/^\d+/unpack(%32C*,qx{hostname -s})%60/e;
s/^([\d*]+\s+)\d+/$1.($.-8)/e; }' /etc/crontab
The above one-liner will randomize the minute and the hour of all run-parts
lines of /etc/crontab on Debian
I calculate the System V sum of the hostname modulo
severity 373152 wishlist
merge 373152 522419
thanks
In my own experience, the only proper approach -- guaranteeing safe
system loads -- is a managed solution, ie either custom crontabs for the
guests or having cron jobs managed by the host (as Russell plans to do).
Nevertheless, I understand the
If you have a many virtual servers and if the cron jobs can run for any
moderate length of time then you have problems which will not be solved so
easily.
My current hack for one virtual server I run is to have the daily cron jobs
run 30 minutes apart (as some DomUs have jobs which run for
I shouldn't say that I implement randomness since that isn't optimal: the
reason I picked IP address was that the general use is to avoid everything
running at once, by using a modulo of the IP address (and optimal spreading)
it meant that jobs on sequentially numbered systems would definitely not
Maybe it's better not to randomize on ip-address but by a general random
value. E.g. lrand48() (with correct srand48()) or value from
/dev/urandom. That way it'll be generic solution. One could then shift
-29...29 seconds.
Folkert van Heusden
--
MultiTail är en flexibel redskap för att fälja
I have a patch submitted with the maintainer that adds randomness based on
the IP address. This should help with both virtual machines and large
server clusters.
--
Modest doubt is called the beacon of the wise.
William Shakespeare
Package: cron
Version: 3.0pl1-86
Severity: normal
I'm using a setting with 6 virtual Debian servers.
All their system cronjobs start at the same time, which eats all the
ressources of the server at the same time (especially updatedb every
morning at 6:25). The servers all basically come to a
8 matches
Mail list logo
