6 ms·
OpenBSD cron(8) now supports random ranges with steps
- kevin_thibedeau 3y agoHow 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.
- aldto 3y agoI read it as the 25 is just a simple step. So the first hour in your example would run at 0, 25, and 50. The next hour would run at 15 and 40, etc.
- g0xA52A2A 3y agoAnother 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 https://man.openbsd.org/man5/crontab.5#s
- hnlmorg 3y agoToday I learned the -n flag. Is this also an OpenBSD exclusive? I have to say, these flags are a really nice enhancement to cron.
- networked 3y agoFreeBSD and NetBSD also implement "-n". There doesn't seem to be a cross-platform port of OpenBSD cron like there are of doas and OpenBSD ksh. (Anybody want to try making one?) Cross-platform fcron has "erroronlymail". https://man.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html https://man.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&... https://man.netbsd.org/NetBSD-9.3-STABLE/crontab.5 https://man.netbsd.org/NetBSD-9.3-STABLE/crontab.5 http://fcron.free.fr/doc/en/fcrontab.5.html#FCRONTAB.5.ERRORONLYMAIL http://fcron.free.fr/doc/en/fcrontab.5.html#FCRONTAB.5.ERROR...
- pengaru 3y agoThat's gross. If the operation shouldn't run concurrently it should use an exclusive flock or similar. It's not just cron that can cause concurrent execution, and if that matters you generally want to robustly prevent it - not just if cron is the executor.
- thiagocsf 3y agoIt’s not gross. It’s a simple solution to a simple and common cron problem Just because it doesn’t consider external executions, it doesn’t mean it’s a bad solution. Horses for courses etc
- pengaru 3y ago> It’s not gross. It’s a simple solution to a simple and common cron problem No, it's gross. By providing that facility in the wrong place it discourages implementing it in the right place to people who come at the problem from the cron perspective. Wrap the command in a flock-running script. That script goes in the crontab entry. When you're inevitably debugging your cron-scheduled command - paydirt! The command serializes itself still while you're manually testing instead of shitting itself.
- eska 3y agoIsn’t that the same? Just because you check a file lock in your script doesn’t mean that other invocations of the program without the script will check the lock.
- pengaru 3y agoNo, it's not the same. The crontab entry reflects what you'd run to reproduce what the crontab does.
- eska 3y agoOk, but your original criticism stated that solving this in cron is bad because the program may be run outside of cron: * It's not just cron that can cause concurrent execution, and if that matters you generally want to robustly prevent it - not just if cron is the executor.* So you did not like that exclusion only worked when triggered from cron. But in your case it also only works when triggered from your script. So cron just made your script an integrated feature and you’re essentially criticizing your own solution.
- mekster 3y agoAn external program but there's run-one program in Ubuntu repo.
- networked 3y agoNice! 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.RANDOM 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
- rollcat 3y agoGiven 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.
- dralley 3y ago>OpenBSD with the simple, obvious solution, that everyone else kinda overlooked Systemd Timers have had this for a while.
- usr1106 3y agoRandomizedDelaySec=
- _2z1p 3y agoThey said simple and obvious, which much of systemd is not. Personally I find the OpenBSD solution far more elegant and UNIXy than the systemd one, but to each their own.
- ijustlovemath 3y agoWhat's more simple than an ini file?
- rodgerd 3y agoReinventing the same features many times over in many different places, of course.
- ratorx 3y agoWhy does the complexity of the rest of systemd matter when comparing the implementation of this feature? What would you say is wrong with RandomizedDelaySec?
- psychphysic 3y agoThis 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
- znpy 3y agoFrom 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.
- compumike 3y agoThis 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.
- ciupicri 3y agoWhy aren't you using systemd timer unit with RandomizedDelaySec? [1] [1]: https://www.freedesktop.org/software/systemd/man/systemd.timer.html#RandomizedDelaySec= https://www.freedesktop.org/software/systemd/man/systemd.tim...
- 1letterunixname 3y agoSome people call it splay. It helps to not have all running instances hug to death telemetry and configuration management servers.
- stevekemp 3y agoYes, I first learned this and the name "splay" from CFengine, back in the day. I put together a small busybox-like collection of sysadmin tools, and one of the subcommands is "splay" to sleep for a random amount of time. It's one of those things that is useful surprisingly often, even outside cron. https://github.com/skx/sysbox https://github.com/skx/sysbox
- krick 3y agoDoesn'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.