Cron in production is a double-edged sword
orchestrate.io
Cron in production is a double-edged sword
1–10 of 58 posts
Re: Cron in production is a double-edged sword
#2These all seem like issues you'd run into with any task scheduler. Error emails, overloading a central resource with many tasks. Most of these aren't particular/limited to cron at all.
Re: Cron in production is a double-edged sword
#3I've been using Dead Man's Snitch[0] in production for a few years. It's been a life saver. Not affiliated, just a happy customer.
Re: Cron in production is a double-edged sword
#4I just started using AWS Lambda for a cron-like job I needed. It supports scheduling now.
Re: Cron in production is a double-edged sword
#5Linux is designed like a 1970's mainframe.
TempleOS is designed like a C64.
I don't see cron as useful for a C64 user.
Re: Cron in production is a double-edged sword
#6I've been using Dead Man's Snitch[0] in production for a few years. It's been a life saver. Not affiliated, just a happy customer. [0] https://deadmanssnitch.com/
Seconded. DMS is the easiest thing to just drop-in on the Nth cron job you add. Eventually you might need something more complicated for monitoring/outages/etc, and that something is probably either a whole lot of Nagios and bailing wire and/or PagerDuty, but DMS is perfect for "I really need Tarsnap backups to not just silently fail."
I also end up creating a lot of Twilio scripts which are either positive control or negative control for the call/SMS, depending on how critical the thing is that I'm monitoring. For example, one of my sites updates an /api/healthcheck result with a timestamp every five minutes if everything is going peachy, and another box polling that endpoint blows up my phone if it fails to get HTTP 200 and a timestamp within the last five minutes. (This works, but I swear I need to tweak it just a wee bit, as today I had my once quarterly woken-up-at-4-AM-because-gremlins-ate-a-single-HTTP-request.)
Re: Cron in production is a double-edged sword
#7These all seem like issues you'd run into with any task scheduler. Error emails, overloading a central resource with many tasks. Most of these aren't particular/limited to cron at all.
I dunno. Cron is particularly bad. Want a sane looking cron? You'll probably end up writing a wrapper script to handle stdout/err. Every time I deal with an annoying dev or proprietary binary, my crons turn to a total mess.
Also: /home/on_a_phone/parse_today.sh `date +%Y%m%d`
Will fail catastrophically because cron treats '%' as a newline character for some silly reason. Have fun troubleshooting that one!
Side note - clean your damn leap second crons, Steve!
Re: Cron in production is a double-edged sword
#8Is there any good open source distributed scheduler that blends both timer based tasks and event based tasks?
Chronos is the only one I'm aware of, but I don't believe it supports event based tasks.
Re: Cron in production is a double-edged sword
#9Is there any good open source distributed scheduler that blends both timer based tasks and event based tasks? Chronos is the only one I'm aware of, but I don't believe it supports event based tasks.
Celery is a task queue that supports scheduling as well, if you're using Python. Backed by several different brokers including Redis.
Re: Cron in production is a double-edged sword
#10I use Jenkins instead of cron. I get an rss feed of processes that exited with non-zero, it captures the output but doesn't e-mail it to me. This is totally not what it's designed for, but it is closer to what I want than cron is.