In Unix and Linux, this functionality is provided by the cron daemon. The cron daemon wakes up once a minute and looks to see if there is anything to execute -- either system jobs (always run as root) or user jobs. If there is nothing to execute, it essentially goes back to sleep for another minute. If there are any jobs to execute, they are run, or started, in unattended mode before cron nods off. While there can be some slight differences between cron implementations, typically spooled jobs are found beneath either /etc/cron.d or /var/spool/cron.

There are slight differences in the versions of cron based upon the distribution of Unix or Linux that you use. For example, SuSE Linux Enterprise Server 9 uses Vixie cron, based on the original AT&T System V’s cron, while others use different implementations. Regardless of the slight behind-the-scenes differences, all work in the same way, and the tools and functionality described in the rest of this article apply to all. Where there are differences, I’ll try to point them out.

Creating a Cron File
In addition to system-wide cron jobs, every user has the default ability to create their own cron table (crontab) file and have jobs run at specific times. You can restrict this ability by creating/editing either "allow" or "deny" files. Depending upon the implementation, these will either be in the form of /etc/cron.allow and /etc/cron.deny or /var/spool/cron/allow and /var/spool/cron/deny combinations. If you use the "allow" approach, then only users whose names appear in this file are allowed to create crontab files. Conversely, if you "deny" users, then only users whose names appear in this file are denied the ability to create crontab files.

The primary utility for working with cron table files is called, simply enough, crontab. This utility offers a number of useful options:

• -e will open the file for editing.
• -l will show the contents of the current file for the user.
• -r will remove the user’s cron job.
• -u allows you to specify a different user than the one you are currently logged in as to view/edit their file.

Each crontab file cannot be longer than 256 lines (entries) and each line within the file is limited to 1,024 characters. There are six fields to each line, and the fields are separated by white space with a common entry looking like this:

1 2 3 4 5 /etc/special_report.sh

The first five fields identify when and what time the job runs, while the sixth identifies the job itself (always use the full path). The beginning fields, in order, are:

• The minute (0–59)
• The hour (0–23)
• The day of the month (1–31)
• The month (1–12)
• The day of the week (0–7; both 0 and 7 correspond to Sunday).

You can specify multiple values in several ways:

• An asterisk (*) matches all possible values.
• A list separated by commas (such as 5,10,15,20) matches any and all of those specified values.
• Two values separated by a dash (-) denote a range that includes the endpoints. For example, "10-20" in the hour field means from 10:00 a.m. to 8:00 p.m.

The following entries are examples of jobs that run at specific times:

• 0 6 * * 1 ABC -- Every Monday at 6:05.
• 10 15 2 * * BCD -- The second day of each month at 15:10.
• 30 18 14 3 * CDE -- March 14 at 18:30.
• 0,10,20,30,40,50 6-18 * * * DEF -- Every day every 10 minutes between 6:00 and 18:00.
• 5 12-16 * * 1-5 EFG -- Five minutes past the hour, every hour between 12:00 and 16:00 on weekdays only.

If the output display from a job is not needed -- which is almost always the case when running in unattended mode -- you can send it to /dev/null to keep any results from being unintentionally mailed to a user with by ending the command with:

> /dev/null

To send successful results, and errors as well, to there, replace with:

2&1> /dev/null

As a good rule of thumb, you should restrict access to cron and the ability to create crontab files to system administrators and other users with a legitimate need.

Working with At
The functionality that cron provides is great if you want to routinely run a job. If you need to run a job only one time though -- still in unattended mode – there’s a better solution: at. Just as cron runs using the cron daemon, at runs using its own daemon (atd). Unlike cron, however, on most implementations, this daemon is not started by default (check ps before trying to submit jobs). You can start it with /usr/sbin/atd.

With at, simply tell it the time of day -- either in 24-hour format or 12-hour format with "am" or "pm" specified -- and the job will run when told. You can also use the words "noon," "midnight" or "teatime" (which means 16:00 or 4 p.m.). If you want the job to run at a point in the future more than 24 hours away, you can use a day format of either MMDDYY, MM/DD/YY or DD.MM.YY or use the phrase "now +" and specify a time unit to count from.

Some examples include:

• 17:31 -- To run the command at 5:31 in the afternoon.
• now -- To run now.
• now + 5 days -- To run five days from now at the exact same time.
• 17:31 Mar 14 -- To run at 5:31 in the afternoon of March 14.
• midnight -- To run at midnight tonight. Other special words are today, tomorrow and noon.

By default, only the root user can use the at command. This can be changed, however, by utilizing either the /etc/at.allow file or the /etc/at.deny file. By default, on most systems the at.deny file exists and holds system accounts that a user shouldn’t be using. If only the at.allow file exists, then only users who are listed in it are allowed to use the at command. On the other hand, if the at.deny file exists, then all users are allowed to use the at command except those listed within this file. To complicate matters a bit, if there is an at.deny file and it’s empty, then only the root user can use it.

Jobs that are spooled for future execution can be listed with either the command "at -l" or "atq."

Individual users will see only their own entries, while the root user can see all. In reality, the listings are to text files stored beneath /var/spool/atjobs. These text files hold a copy of environmental information that was applied when the user created the job, as well as the commands within the job itself. Prior to execution, the command can be stopped with either of the following commands and the job number: "at -d" or "atrm."

You can submit the job using the -f option and specifying a file name or just specifying a time on the command line. When you do the latter, the prompt changes to the PS2 prompt (>, by default), and you can enter as many commands as you wish to run at that time. When you’re finished, press Ctrl+D to return to the PS1 prompt.

Here’s an example of scheduling a job to run at a later time. Notes about the action have been added in parentheses:

$ at 18:05
> /home/edulaney/myexample
> (Press Ctrl+D)
job 7 at 2005-10-16 18:05
$
$ atq
7 2005-10-16 18:05 a
$

This last listing shows it’s the seventh job that’s been assigned recently (as a user, you only see your own) and the date and time it’ll run. The "a" indicates an at job. There can be other jobs spooled and such. During the duration that it’s spooled, there’s a file representing it with a very odd name (cryptic format) beneath /var/spool/atjobs. In this case, an example of the filename would be "a0000700f71ec1," and its contents (which you must be root to see), are listed below:

#!/bin/sh
# atrun uid=502 gid=100
# mail root 0
umask 22
HOSTNAME=noname; export HOSTNAME
LOGNAME=edulaney; export LOGNAME
_ETC_PROFILE=1; export _ETC_PROFILE
HELPPATH=/usr/openwin/help; export HELPPATH
MAIL=/var/spool/mail/edulaney; export MAIL
PAGER=less; export PAGER
CLASSPATH=/usr/java/lib/classes.zip; export CLASSPATH
HOSTTYPE=i386; export HOSTTYPE
PATH=/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/
  X11R6/bin:/opt/teTeX/bin:/opt/kde/bin:/usr/java/bin; export PATH
KDEDIR=/opt/kde; export KDEDIR
HOME=/home/edulaney; export HOME
USER=edulaney; export USER
LESSCHARSET=latin1; export LESSCHARSET
JAVA_HOME=/usr/java; export JAVA_HOME
HOST=noname.nodomain.nowhere; export HOST
OSTYPE=Linux; export OSTYPE
OPENWINHOME=/usr/openwin; export OPENWINHOME
SHLVL=2; export SHLVL
cd /home/edulaney || {
echo 'Execution directory inaccessible' >&2
exit 1
}
/home/edulaney/myexample

Notice how all relevant information about the user has been placed here: User ID, environmental variables, etc. This prevents a user from running a command through at, which he/she would not have access and permissions to run otherwise. The very last line is the command to run; it’s always recommended that the full path be given as there’s no relative path for the service that runs the command.

In addition to the -f option mentioned earlier (used to specify the shell script that should run), other options include -q to specify a queue to use and -m to send mail when the job is done. An example of starting a script in 10 minutes would be:

$ at –f myscript.sh now+10 minutes

Or, to start it at 5 p.m., four days, from now:

$ at –f myscript.sh 5pm + 4days

Companion utilities mentioned include atq (to list pending at jobs) and atrm (to remove an at job from the queue before it runs). There’s also another command, batch, that can be used to specify the jobs are to run when the system load level dips below 0.8.

Less Work, Less Stress
In this article, we’ve examined the concepts and utilities associated with automating jobs in the Unix and Linux world. Knowing how to correctly configure tasks to run unattended can greatly simplify administration.