One of the most widely used utilities in the world is cron.

Cron executes a recurring task or program on Linux or UNIX machines. This simple utility is incredibly valuable to IT admins, developers, and other technical professionals. The core of cron is the crontab configuration file where sys admins direct which tasks should be executed and when. Crontab, which is short for cron table, is effectively just that, a table that specifies the runtime of jobs.

The core of the crontab file is the cron expression. Depending upon which version of cron you are using it is five fields separated by spaces and then the command or program that you would like to execute.

Graphical description of the crontab scheduling format.

Image from WebEnabled.

The fields are as follows:

  • Minutes – this field can be between 0 and 59
  • Hour – this field can be between 0 and 23
  • Day of month – this field can be between 1 and 31
  • Month – this field can be between 1 and 12
  • Day of week – this field has 0 to 6 (with 0 = Sunday and 6 = Saturday, and to make it more complex 7 is also Sunday as well as you can use the names of the days)
  • The next area is the execution path of the command or program that you would like to run

The Challenges You Might Run Into With Crontab

While this all seems pretty straight forward the challenge comes in when you actually try to execute putting all the pieces together. Because the cron expression format is arcane, compared to today’s coding standards, it creates headaches for admins. For example, this is a line from a crontab file that executes a command every day at 2:15am to remove all files in /tmp that have not been accessed in the last 30 days:

15 2 * * * /usr/bin/find /tmp -type f -atime +30 -exec rm -f {} \;

Each user on a Linux or UNIX machine is allowed to run their own crontab file. This potentially creates a number of challenges including conflicting job execution, resource contention, and duplicate execution. Another complicating factor is that after a cron job has run, there is no output displayed to the user. There are no failure or success codes. Another note that is critical is that if the cron daemon should die unexpectedly all cron jobs will not run and there may not be any notification to the user. As many admins know, this has caused disks to fill up and systems to crash hard.

Although cron is a staple for IT admins, there is a better, easier way to schedule and execute jobs. JumpCloud’s Directory-as-a-Service® solution, or DaaS, offers command execution capabilities. Think of DaaS as a centralized cron capability with a full UI. Admins can simply go into the JumpCloud commands tab and create their scheduled jobs.

Here’s how you’d do it:

  • Name a job you want scheduled
  • Add the command, script, or program that you want to execute
  • Pick the schedule to run it on with a simple UI
  • Identify all of the different machines that they would like the job to run on

When it’s time for the job to run, a success or failure status appears in the UI and all results are saved. As a result, admins have full visibility on the task and its success.

In short, JumpCloud’s command execution capability gives you all of the benefits of cron without the drawbacks. No arcane format to fight with in the crontab file. No conflicts and full results. And, best of all, you can centralize control over cron.

If you have fought with crontab jobs and want a better way, give JumpCloud a try.