A Scheduler for the Internet

That may have been a Centos5/6 specific thing and it was probably caused by too frequent -HUP ing it, but it didn't feel like the decades made it that stable..

> Smallest resolution is 1 minute — If a task needs to run every 30 seconds, you can’t do it with cron.

This is the only one I can see that could be an issue. But engineering wise, I don't think this is the best solution (OP's). You still have overhead if you're launching from an external tool. I'd probably run this inside the application (like they do here).

> Error handling — If a job fails, what should happen? Solutions have been built to solve this single problem. Developers love adding more band-aids rather than admitting there is a better way. Deja Vu?

If it fails to launch or what was supposed to run failed? Going to assume whatever was supposed to run failed since any application can fail/crash. Even celery beat which is what they propose here.

You handle the condition. The same thing you'd do anywhere,

    true && echo “True” || echo “False”
    false && echo “True” || echo “False”

Cron by default mails stdout and stderr. This is a log. Regarding the second point, I'm assuming it means redirects. If so, that's an issue of misconfiguration and not understanding your tool. Same with any tool/program.

> Working with cron pulls you out of the application — cron is a system level process. Not an application process.

This suggests another process to run jobs (`celery -A proj beat`). It’s another dependency to manage and requires you to launch it. So it still handles an external process.

> It’s challenging to give application developers access to anything at a system level. Developers shouldn’t care where their application runs… A good example of this is timezones. If a system person changes the timezone of a server, the cron may run at a different time than expected. The less the app developers have to worry about what they run on, the better.

So the author is saying this applications doesn’t know about time zones? Celery Beat does know about them. It works on UTC by default but it can be configured.

Regarding giving developers access to system settings... why? This article says they devs can't log cron correctly or deal with timezones, allowing all devs to be able to manipulate this is crazy. If the server runs more than one thing, the mess would be horrible.

Timezone misconfiguration on the server, or any kind of misconfiguration, could be an issue. But so is an applications being misconfigured and running on a wrong timezone. If teams can do things like changing timezones without coordinating and talking, that's an internal issue.

> The defenses I've heard for "professional" software and systems engineers using cron in production software are appalling and I find the behavior negligent and to be a terminable offense.

Except for the 30s resolution, I haven't seen a good reason on this article that doesn't boil down to misconfiguration, not knowing how something works or communication.

30s resolution can be done easy enough,

    #!/usr/bin/env bash
    while [ true ]; do
      sleep 30;
      #run whatever you need. 
      # Append & if you don't need to wait for it to finish 
      /path/to/program
    done

Addressing your specific items:

Dependencies. Depending on which of these you're referencing, the package manager (which installs a given cron script), configuration manager, or script itself, can and should test and check these.

Multiple hosts. There are numerous multi-host utilities, ranging from SSH extensions / utilities to full multi-host configuration tools (Ansible, Salt, Chef, cfengine, Puppet, etc.) At heart, this isn't cron's problem. It's a schedular, not an orchestrator.

Error handling. Your script's issue, not crons. Cron is a schedular, not an error handler.

Branching. Not sure what you're referencing, but again, the task of the script, generally.

Sub-minute granularity. Cron is a schedular, not a daemon substitute. If you need a daemon operating at sub-minute granularity, write a daemon.

Reporting. This is the job of your logging facility, generally.

Metrics. This is the job of your accounting facility: systat, syslog, etc., etc.

Pools of jobs. This is the job of your script(s), generally. If you have a set or sequence of tasks, trigger the master with cron, and have it manage the set. Again, cron is a scheduler, not an orchestrator.

Priorities. Nice.

Queue jobs. You want 'at' or 'batch', not cron. Cron is a scheuler, not a job queue.