Cron Scheduling: An Old Fallback

clock overlaid on calendar

Cron is our old frenemy: we love to hate it and we hate to love it. Cron, the simple job scheduler, has been shipped with UNIX and Linux since the dawn of time…or at least the dawn of the computer age. The crontab scheduler is great for simple tasks, but there are three primary problems that arise when you try to rely on cron scheduling as your primary vehicle for automation.

The first problem is that cron is not suited for complex, event-driven tasks, the type of jobs that automate tasks across your enterprise. Programmers love using cron for simple tasks: running job A at a very specific time. In many cases, writing a crontab file to execute this command is faster than accessing the enterprise scheduler to run the same task. But what if you have cross-system dependencies as part of your workflow? Cron can’t react to or incorporate tasks that complete on your Windows or IBM machines into its workflows—and you’re left with a problematic gap in your job schedule.

Second, cron requires scripting skills, which precludes an end user community from interacting with and interpreting the job schedule. An enterprise job scheduler like JAMS is easy to use, even for end users. In particular, JAMS’s dashboard makes it easy for end users—especially executives—to monitor and understand the operations and success of the job schedule.

Finally, cron is missing a lot of modern features that make end users’ lives a lot easier when they are interacting with a job schedule. Cron does not include robust features for error reporting or error handling, features that help programmers and executives rest easy knowing that their job schedule is in good hands—even when no one is actually monitoring it manually.

UNIX Cron Job Scheduling: The Danger of Different Implementations

Over the years, there have been a lot of distributions of the Linux job scheduler and UNIX job scheduler. As the servers change, so, too, does cron. Here is an example of the type of problematic discrepancies that can occur with different versions of cron. Some implementations of cron won’t run the last command in a file if the crontab file doesn’t end with a new line.

Another difficulty with cron job scheduling is arcane syntax rules that are required to use cron. For example, if you want to run multiple commands within one job, you need to use special syntax, and this only works with certain Linux and UNIX shells. Understandably, it is very difficult, if not impossible, for end users to participate in the job scheduling because of this arcane syntax. If they wanted to specify a schedule in cron that runs on the 1st and the 15th of the month that runs every hour on those days, they would need to learn cron syntax. Overall, scripting with cron requires special knowledge that limits the access to and control of the cron job schedule to just a few people. This prevents the schedule from being beneficial and accessible to other important stakeholders.

More specifically, one issue that cron users run into is having a command that works on the command line but doesn’t work in the shell when they put it into cron. This could be caused by having a command shell session that isn’t set up when cron runs. They could have environment variables that aren’t there, as well. If the path and environment variable aren’t set up, the cron job won’t run. The second thing that could cause this issue is that the permissions aren’t set up or that they’re using the wrong user. If that happens, then the program isn’t going to have the correct authority to the data files it needs to access. The third thing that could cause the job to fail is that a user could have configured cron to run with the wrong shell: the syntax won’t work if they’re using the wrong shell and the cron job will fail.

Cron Job Scheduling Vs. Creature Comforts

So though cron is a great job scheduling tool for UNIX, Linux, and AIX users who want to automate simple one-off tasks, it lacks the robust features of a true enterprise scheduler.

Cron has weak history reporting; you would have to scan through an entire text file in order to gain an understanding of that job and its output. There are also no scheduling exceptions in cron, which means that there is no way to hold a job in cron without taking it out of that crontab file. Though you can do some event-driven stuff with cron, it is difficult to implement and often very error prone because of the advanced scripting involved. Finally, in cron, there is no queueing, which means that there is no specific ordering of jobs. You won’t be able to protect your resources from having too many things running out of it at once.

Get the Edge with Enterprise Scheduling

Enterprise job scheduling software gives you the advantages that cron lacks: detailed job history reports, event-driven options, alternate reactive paths, automatic notification, central monitoring, and more. JAMS, in particular, makes it easy to incorporate your existing cron job schedules into the wider enterprise schedule. This way, you can make your isolated cron commands reactive with other business-critical applications and platforms, giving your cron job schedule more power than ever before. With JAMS, you can continue to schedule jobs with the familiar cron syntax, while you gain many new scheduling options and features.