Introduction

Any user can enter scheduled events -- provided user input is allowed in the configuration file. Entered events are then updated in real time. One of the keys to the success of the "Magic Calendar" system, in addition to user input, is the automatic deletion of passed events. Nothing will cause a site to loose creditability faster than outdated information.

Every day at one minute after midnight local time (0500 GMT) an automatically executed Perl script purges any outdated events from the calendar database.

The beauty of unattended jobs is non-intervention by the owner of the system, or anyone else for that matter. Jobs can be run as frequently as every minute (Don't do it or you loose the privilege of running these background jobs.) You can run a job at a specified time every day, once a week, twice a month, every other month, you get the idea.

These jobs are made possible using a command called crontab. Two caveats, crontab only works on a Unix system and not all Internet Providers allow user background jobs.

Do you have what it takes?

/etc/cron.d/cron.allow

Alternatively, the administrator can let anyone use crontab and exclude specific user with the file:

/etc/cron.d/cron.deny

To determine how your system is configured, first enter the following at the command line:

more /etc/cron.d/cron.allow

more /etc/cron.d/cron.deny

In summary, users are permitted to use crontab if their names appear in the file /etc/cron.d/cron.allow. If that file does not exist, the file /etc/cron.d/cron.deny is checked to determine if the user should be denied access to crontab. If neither file exists, only the system administrator -- or someone with root access -- is allowed to submit a job. If cron.allow does not exist and cron.deny exists but is empty, global usage is permitted. The allow/deny files consist of one user name per line.

Setting up A crontab job

1. minute (0-59),
2. hour (0-23),
3. day of the month (1-31),
4. month of the year (1-12),
5. day of the week (0-6 with 0=Sunday).

Each of these patterns may be either an asterisk (meaning all legal values) or a list of elements separated by commas. An element is either a number or two numbers separated by a minus sign to indicate an inclusive range. The specification of days may be made by two fields, namely, the day of the month and day of the week. If both are specified as a list of elements, both are utilized. To illustrate, 0 0 1,15 1 would run a command on the first and fifteenth of each month, as well as on every Monday at exactly mindight. To specify days by only one field, the other field should be set to *. The entry, 0 23 * * 1 would run a command only on Mondays at eleven PM.

A minute specification of 0,30 would indicate the job is to be run on the hour and half hour. Likewise, a day of the month entry of 1,15 would initiate execution on the first and fifteenth of the month.

Notice the hour is in 24 military type time, 0 in midnight and 13 is one in the afternoon. If it is imperative your job runs exactly once every day, don't schedule it during the "witching hour" when daylight savings time changes occur in spring and fall.

The sixth field of a line in a crontab file is a string that is executed by the shell at the specified times. A percent character in this field (unless escaped by \) is translated to a new-line character.

Crontab jobs are being executed from a system directory. Make sure you include and explicit path to your script. Let's assume we want to execute a Perl program, purge.pl, every morning at one minute after midnight. Additionally assume the full path to the script is /usr/users/goodguys/cgi-bin. The full command would be:

1 0 * * * /usr/users/goodguys/cgi-bin/purge.pl

Execute one minute after midnight, every day of the month, every month of the year, and every day of the week.

If you're not sure of the full path to your script, go to the directory and issue the command:

pwd

This is the "print working directory" command.

The requirement for explicit paths also apply to any "require" library file used in a Perl script. Use something along the lines of the following:

$Library = "/usr/users/goodguys/cgi-bin";

require "$Library/mailstuf.lib";
require "$Library/dates.lib";

In addition, any files opened while your script is executing also require explicit path names.

Putting it all together

Creating your first crontab job is a three-part process:

1. Create and test a script to perform the desired task,
2. Create a file containing a line to schedule the job,
3. Upload the file to your system.

When creating the script remember that crontab jobs are background tasks. There is no terminal attached to a crontab job so there should be no print statements that normally write to the screen. (It is possible to redirect such print statements.) The same consideration hold true for requesting user input.

Let's create a Perl script to simply write the time a date to a file.

#!/usr/bin/Perl
# This is file cron-test.pl
open(DATA,">>/usr/users/goodguys/cgi-bin/data/cron.test");
@Now = localtime(time);
print DATA "@Now\n";
exit;

You will have to change your path to the cron.test file and possibly the path to Perl. Test the script to make sure it writes to file cron.test every time it's executed.

Next create a file to hold your crontab instructions. Let's call it "cron.job". Let's also have our script execute one minute after the hour, every hour.

1 * * * * /usr/users/goodguys/cgi-bin/cron-test.pl

The last step consists of uploading the contents of your "cron.job" file to the system crontab spool area. Enter the following at the system prompt.

crontab cron.job

crontab commands

There are four crontab options:

crontab [file]
crontab -r
crontab -l
crontab -e

crontab [file] copies the specified file into a directory that holds all users' crontab jobs. The -r option removes a user's crontab from the crontab directory. crontab -l lists the user's crontab file. The -e option spawns an editor containing the user's current crontab jobs as shown using crontab -l. When you save the file, it automatically updates the crontab when exiting the editor.

If for some reason the crontab job does not run proPerly, any generated output or errors messages will be mailed to you. Standard output and standard error can be redirected, but that's another tutorial.

If you would like additional detailed information on crontab, enter the following at your Unix prompt.

man crontab

Summary

Well there you have it sports fans. Thinking about an automatic reminder system? How about performing a log summary the first of every month? Let your imagination run wild. If you come up with any good ideas let me know.

Urb LeJeune urb@usats.com