The following is a guest post from Gwen Davis of hostingobserver.com.

History

The first cron was written in the early 1970s for Version 7 UNIX as a system service (also known in UNIX as a daemon). The algorithm, invoked from the /etc/inittab location whenever the OS entered a multi-user mode, was simple — every minute, it checked a directory for any files set to be run at the current date/time, and ran any it found under superuser root. The next version of cron, created for the release of UNIX System V, extended capabilities beyond the superuser root to all users.

Cron, ported to BSD, remained unchanged for the life of UNIX System V and its derivatives: Solaris, IRIX, HP-UX, and IBM AIX. Vixie cron (now called ISC Cron) were developed for Linux in 1987, and Redhat Linux has cronie and anacron, all of which have contributed to the growth in Linux server administration.

Cron Hosting Basics

There are three basic characteristics for the best web hosts for Cron, these are Linux hosting, cPanel hosting and unlimited hosting. However, this does not mean that you will never have the ability to run cron jobs if your hosting plan has one or two elements missing. From here on we will discuss the workarounds available for each criteria.

cPanel and Cron Commands

For those of you without Cpanel to easily configure your Cron, you will need shell access to go inside the crontab directly to configure it. Here are some basic commands and syntax for manually handling Cron:

- "crond start" (Starts the cron daemon)
- "crond stop" (stops the cron daemon)
- "ps aux | grep crond" (check to see if cron daemon is running)
- "crontab -l" (list all cronjobs set by root user)
- "crontab -u -l" (lists all cronjobs set by username)
- "crontab -e" (edit a cronjob for root user)
- "crontab -u -e" (edit a cronjob for username)
- "crontab -r" (remove all cronjobs of root user)
- "crontab -u -r" (remove all cronjobs of username)
- "crontab " (imports cronjobs from file for root user)
- "crontab -u " (import cronjobs from file for username)

The default editor software for editing cronjobs is vi.

A crontab file contains lines for definition of the environment and the runs.

The first four lines of a typical crontab file are:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

SHELL is the variable that specifies which shell environment should be used.
PATH is the variable defining the path for execution of specific commands.
MAILTO is the variable specifying the username which will receive any output via email. If empty (MAILTO=””), then no email will be sent.
HOME is the variable that sets the home directory for cronjob execution.

All the lines that follow look like this:

42 4 1 * * root run-user /etc/cron.monthly >> /dev/null 2>&1

The format is:
Minute Hour Day Month Dayofweek User Command Location Output
where

• Minute: any integer from 0-59
• Hour: any integer from 0-23
• Day: any integer from 1-31 (max must be valid for any specified month)
• Month: any integer from 1-12 (or jan, feb, etc.)
• Dayofweek: any integer from 0-6 (or sun, mon, etc.)
• User: “root” or username
• Command: name of job to be run
• Location: directory where command is located
• Output: all output goes to trash can

More on Output:

“>> /dev/null 2>&1” means the cronjob sends both standard output and error output to the trash can. If you want to save both the standard and error output, you can use “>> /home/user/some.log 2>&1” instead.

An asterisk (*) can be used as a wildcard to denote all possible values — an asterisk in the Month position means every month of the year.

So, in the example given above, the job run-user, located in the /etc/cron.monthly directory, will be run at 4:42 AM on the 1st of every month.

A comma (,) can be used to create a list of values — for example, “4,5,6” means 4, 5 and 6.

A hyphen (-) between two integers can be used to denote a range of values — for example, 2-5 means 2, 3, 4, and 5.

A forward slash (/) followed by an integer denotes step values — for example, 3/5 in the Hour field means the job is run first at 3 AM, again at 8 AM, again at 1 PM, and so on.

Every minute, the /etc/crontab directory is checked and read, then the /etc/cron.d directory and then the /var/spool/cron directory. Any entries found that match the current date/time will cause the specified file to be loaded into memory and executed.

Several other subdirectories are also checked periodically:
– /etc/cron.hourly
– /etc/cron.daily
– /etc/cron.weekly
– /etc/cron.monthly

Exit values returned by crontab are either zero (success), or a number greater than zero (error).

Cron and Email Management

As discussed, the output from Cron is automatically mailed to the process owner or the person specified in the MAILTO variable, as such cron jobs can be used to take care of standard email hosting and system maintenance functions, such as server backup, automatic email loads, and scanning incoming mail for malware and viruses. For email management, cron jobs can communicate with multiple websites, delete spam from mailboxes or distribute overnight content to subscribers — you can even use cron jobs to do monthly expired-member purges of your subscriber database, or summarize the demographics of your current mailing list. Any email management task that you can set up as a batch job, you can set up as a cron job.

Unlimited Resource and Cronjobs as a Service

If your host cannot handle the load of hosting unlimited resources, Cron has become an additional remote service offered by other online companies. For a fee, the service provider will allow you to schedule your own cron jobs over the Internet. With the extra service more attention must be paid, of course, to file locations when setting up the cron job, but the added flexibility this gives to webmasters more than makes up for the added complexity. Note that the key features to look-out for in choosing a good 3rd party cron job service are refresh rate, run time, quantity– how many jobs can be scheduled, and flexibility in the type of scripts to be run.