Or schedule your cron job for :00, but add "sleep `jot -r 1 0 3600` &&" to the start of the command. (jot is a BSDism, but I assume you can do the same with GNU seq.)
This is a pain when deciphering a series of events later, though, because you don't know when a particular job was supposed to start. I'd prefer the delay to be stable on a per-host basis.
We just went with a single group text file with all the jobs and which ones could be spread out. Saves the programming and gives the sys admins / DBAs an idea what goes when.
Comments
Use the following shell command to decide when to run cron jobs.
It's not a CSPRNG, but good enough for this kind of load balancing!Or schedule your cron job for :00, but add "sleep `jot -r 1 0 3600` &&" to the start of the command. (jot is a BSDism, but I assume you can do the same with GNU seq.)
This is a pain when deciphering a series of events later, though, because you don't know when a particular job was supposed to start. I'd prefer the delay to be stable on a per-host basis.
Don't use that for hourly jobs, though - things are liable to break when you randomly run a command at, say, 12:59 and 13:00.
Right, I usually do that for my daily jobs.
sleep $[RANDOM/3600] works everywhere without requiring jot/seq etc. on BSD/Mac/Linux.
That will be a number between 1 and 10 ($RANDOM only goes to 32767), sleep $[RANDOM/10] would be better. :)
This might be platform dependent though, I can't find any standard RAND_MAX in bash so it's difficult to make this work everywhere.
This works in (da)sh (tweak 2 and 65536 if needed):
s/\//%/ I assume?
Oops
yeah.We just went with a single group text file with all the jobs and which ones could be spread out. Saves the programming and gives the sys admins / DBAs an idea what goes when.