Once again, OpenBSD with the simple, obvious solution, that everyone else kinda overlooked. I hope every other cron out there copies and ships this as soon as possible.
Systemd Timers have had this for a while.
Personally I find the OpenBSD solution far more elegant and UNIXy than the systemd one, but to each their own.
What would you say is wrong with RandomizedDelaySec?
[Timer]
OnCalendar=daily
RandomizedDelaySec=12h
https://www.freedesktop.org/software/systemd/man/systemd.tim...
Ie seconds if no units specified.
Sounds like a lousy standard if the correct way to use it is to say "I want to delay by 12 hour seconds". What is even "12 hour seconds"?
"Sec" suffix indicates time and implements a default of seconds, where a suffix to the value indicates a change in unit.
It would be like Asking "Memory Allocation(MB)" but accepting "12G" for 12 GB.
RandomizedDelaySec=Even if their cron does...
Proper design reduces complexity. The above adds a lot of complexity, and thus it's a hack. Not the appearance.
Otherwise with your standard of hack anything beyond hello world and baby's first input are hacks because everything else requires boilerplate.
https://github.com/freebsd/freebsd-src/commit/f5896baf9c429c...
For example, instead of "0-59/10" in the minutes field, "0~59/10" can be used to run a command every 10 minutes where the first command starts at a random offset in the range [0,9]. The high and low numbers are optional, "~/10" can be used instead.But the above point is still true: many jobs take a few minutes to run. 60s of dispersion in start time is better than nothing, but you really want more.
(In this case, things are still quantized to a minute boundary, so you'd really want both).
If the delay is at the reading side, away from Akami, through a cache, perhaps 10 concurrent requests for X would result in ten lots of data transfer as it isn't in cache yet, but 10 with a short delay is enough to prime the local cache on the first request before the rest start.
There are a number of reasons a sudden glut of activity could balloon bandwidth or CPU/memory costs more than you might expect.
Without a chunk more detail about the system in question, this is just random speculation of course.
Thinking about this-- this is Akamai, who has historically charged for midgress. Liveness of cache could be very important.
They're on different timescales. The OpenBSD start times are still quantized to the minute, I believe.
Both solutions would complement each other.
It was such a breath of fresh air compared to Linux at the time because it was a coherent, engineered, documented system. When you didn't always have reliable internet (and at least for me, even when I did have it was something like 128K DSL), it was a huge deal to have well written man pages, where as on the linux half the time time the man page woud just tell you to scream into the void, err, run gnu info.
This was still in the period when the GPL scared off corps.
It kind of feels like this is putting the policy of "don't all go at once" into the cron mechanism, which is just starting jobs at desired times.
sleep $((RANDOM%=60))
...or longer, at the top of the script your cron is running.
Firstly, OpenBSD is a niche OS, meaning the absolute magnitude of OpenBSD cron jobs out "in the wild" is relatively low.
Second, my understanding is that this is a client-side feature. I.e. if I run a service, this feature only benefits me if a significant portion of my users opt into it.
Third, I have an unsubstantiated suspicion that cron usage relative to systemd usage is also on the decline.