OpenBSD cron(8) now supports random ranges with steps

Given how taxing the "thundering herd" effect can be on mirrors, websites (RSS readers!), you'd think this sort of thing should've been in cron since at least mid-90s.

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.

    RandomizedDelaySec=

  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.

Another nicety OpenBSD's cron gained not long ago was the "-s" flag to ensure only a single instance of command will be run concurrently.

https://man.openbsd.org/man5/crontab.5#s

Nice! To me this is a small but meaningful differentiator for OpenBSD. It is similar to the "random" feature in my favorite cron, fcron: http://fcron.free.fr/doc/en/fcrontab.5.html#FCRONTAB.5.RANDO....

In crons that do not support something like this, you can introduce a random delay with a Perl oneliner. For example,

  # Start within the first 10 minutes of a matching hour.
  0 */8 * * * perl -e 'sleep rand 10*60' && ~/.config/jobs/fetch-tcl-logs

  0 */8 * * * sleep "$(jot -r 1 0 599)" && ~/.config/jobs/fetch-tcl-logs

    sleep $((RANDOM % 600)) && fetch-tcl-logs

How would this work with a step that isn't divisible into the range for the field? Given minutes 0~59/25 with a random offset of 0 there will be an event at 0, 25, and 50 minutes past the hour. On the next hour does it start at 0, 15, or a new random offset? i.e. constant offset, constant step, or regenerated offset.

This is a nice feature at the minute-resolution level. I think something at the second-resolution level would be helpful too. For example, I have a cronjob on my Raspberry Pi at home that runs every minute and does a simple check-in with Heii On-Call so I get alerted if there's a FIOS outage or the pi breaks. I ended up writing a little bash script like this:

    #!/bin/bash
    set -e

    HEIIONCALL_API_KEY="redacted_api_key_goes_here"
    HEIIONCALL_TRIGGER_ID="redacted_trigger_id_goes_here"

    AUTHORIZATION_HEADER="Authorization: Bearer ${HEIIONCALL_API_KEY}"
    CHECKIN_URL="https://api.heiioncall.com./triggers/${HEIIONCALL_TRIGGER_ID}/checkin"

    if [ "$1" != "--now" ]; then
      RANDOM_SLEEP=$[ ( $RANDOM % 55 )  + 1 ]
      echo "Sleeping ${RANDOM_SLEEP} seconds before checkin..."
      sleep ${RANDOM_SLEEP}s
    fi

    echo "Checking in..."
    exec curl \
      -X POST \
      --retry 5 --retry-connrefused --retry-max-time 15 --retry-delay 1 \
      -H "${AUTHORIZATION_HEADER}" \
      "${CHECKIN_URL}"

This script ~/bin/heiioncall-checkin.sh gets called by crond every minute at exactly :00 seconds, so my expected maximum timeout between check-ins is approximately 120 seconds. And I can skip the sleep with "--now" flag for testing. But I'd much rather have this random offset behavior be something optionally built-in to cron, I suppose.

This is useful. Many services that run periodically can end up with odd patterns emerging.

E.g. Tor network capacity varies over the month due to bandwidth management tending to happen at the begining/end of months

Some people call it splay. It helps to not have all running instances hug to death telemetry and configuration management servers.

From this thread is emerging that pretty much most operating systems had this for a while in some forms… except maybe openbsd (and a few others?).

Btw congrats to the openbsd people for catching up.

Doesn't make me very excited, since I strongly feel standard cron implementations should've been deprecated long time ago anyway. I mean, consider dkron, for example. Forget k8s and web-UI and all that nonsense, its YAML configs are simply way more clear, readable and powerful, than the usual crontab syntax. Why cannot I have the same with plain simple non-distributed cron?!

Also, just as a sidenote I'm not willing to seriously discuss: I seriously doubt I'd personally ever use random ranges in production. I understand what problem it's supposed to solve, but generally I just really don't want anything random in my systems. If it conflicts with some other cronjobs or whatever, I'd like it to break down deterministically — preferably, all the time, so it's easier to spot, track down and fix it. If it causes any load spikes, I'd like these spikes to be regular, so that I can see that and manually tweak run times so that it'll be more even. If any problems arise, I'd prefer them to arise after somebody changed something, and not just magically one Saturday evening a couple of months later.

The only situation I can think of right away when this is acceptable, is if I have lot of nodes with the same cron config, so it's my attempt to spread out workers of the same type that I know would start at the same time otherwise. But then, why the fuck do I have such a degenerate architecture in the first place?! Maybe I should think about replacing that by something a little more sustainable, like, uh, a centralized scheduler? No, I mean, it's definitely a solution — a quick and easy one, at that — but even then it seems like a solutions to a problem that shouldn't have existed in the first place.