Two Open Source Software Alternatives to Cron

A few weeks ago, we looked at using Corntab to make it easier to create entries for cron. What if you want to avoid cron altogether? You can, thanks to several cron alternatives.

One alternative is hcron, a GPLv2 alternative to cron. Written by John Marshall, hcron has several advantages over cron. First, hcron’s event definitions are much easier to read and are more expressive.

But hcron also addresses a few problems cron didn’t anticipate, leaving aside its arcane syntax. When you run a cron job, you must kludge together something in the job itself or in the command you pass to cron to send an email when a job is completed. The hcron utility is expressly designed to allow for an email when the job is run.

The real kicker is remote execution. When cron was conceived, the computing environment was much less complicated — and less networked. Today, it’s hard to imagine any professional IT worker not having to manage remote machines. Hcron is designed for remote execution as well as local.

The downside to hcron? It’s relatively unknown and not widely packaged. If you want to give it a shot, you may need to compile it yourself. Hcron is hosted on Google Code, and you’ll find Debian packages along with a PDF user guide and article on hcron. It looks like a nice middle-ground solution between a full-blown system administration framework (like Puppet) and an old-school utility (like cron).

The Venerable at Utility

What if you just want to run a job once? Setting up a cron job seems like a bit of a hassle, doesn’t it?

For one-off jobs, turn to the at utility. It’s very simple to use, and you can fire off a one-time job without a lot of fuss. Run at time < script.sh and at will run the script and then exit. For example:

at 9am -f script.sh

Will run the script at 9 a.m. — if it’s past 9 a.m., then it will run the job tomorrow. And that’s it; the job will run once. If you want to see what’s scheduled, just use the atq command to see what you will be running. Note that the -f option specifies a file for the command input, whereas you can also just provide the commands via standard input (such as using the < script.sh method).

See the at man page for more, but it’s a fairly simple utility to use.

Summary

If you’re scheduling jobs in a shared environment — that is to say, a work environment or educational institution if you’re using school computers — stick with cron unless you have a very good reason not to. It may be old and creaky, but it’s a standard utility so if someone comes along after you and wants to tweak scheduled jobs, they’ll look for a crontab first. If you do have a good reason to use an alternative like hcron, be sure to have documentation on hand of what you’ve done and where to find information on the alternative that you’re using. Obviously, for one-offs like at jobs, it’s not going to be an issue.

Come to think of it, it would be a good idea to document your cron setup as well.

For personal computers and home environments? Use whatever makes you happy and you’re comfortable with. cron does not fit that bill, dive in and try the alternatives and see if they work for you.