How cron and at Commands Work


Contents

About this document
    Related documentation
About the cron and at commands
Contents of the /var/adm/cron directory
More about cron commands
    Setting up a crontab entry
    0481-086 and 0481-079 errors from the cron daemon
    Listing crontab entries
    Ensuring cron is working
    crontab entry is changed but cron is not running
A job runs from the command line but not from cron
    Getting crout* files in /tmp
    Sending and routing cron mail
More about the at command
    Defining the at command
    Submitting an at job

About this document

This document describes how the cron and at commands work and applies to all versions of AIX.

Related documentation

The product documentation library is also available:
http://www.rs6000.ibm.com/resource/aix_resource/Pubs/index.html


About the cron and at commands

cron is a daemon that is started by the init process (via /etc/inittab) during the startup of the system. The cron daemon is responsible for running jobs (processes) at scheduled times, days of the week, or days of the month. Processes that are run on a regular basis are usually placed in a crontab file in the /var/spool/cron/crontabs directory.

The at command is used for jobs that only need to be run once. These jobs are run from either the command line or from scripts. The at entries do not go in the crontab files.


Contents of the /var/adm/cron directory

Below are examples of what should be in the /var/adm/cron directory:
      prw-------   1 root     cron           0 Jul 23 15:16 FIFO
      -rw-r-----   1 bin      cron           4 Sep 30 1997  at.deny
      -rw-r-----   1 bin      cron           3 Sep 30 1997  cron.deny
      -rw-rw-r--   1 bin      bin          272 Aug 05 11:27 log
      -rw-r--r--   1 root     sys         1328 Sep 18 1997  queuedefs
FIFO

FIFO is a named pipeline used by cron. This file must have a p for the filetype entry. Make sure that the permissions for the FIFO file look exactly like the sample entry shown above.

log

The log file records the PID (process identification number) for the cron program, recording the time and the data stamp. This file should be monitored. Error messages are recorded here for various conditions.

Following is an example of an error message found in the log file:

           Out of disk space for a temporary file: There is
           not enough space in the file system.
           read: no such file or directory
queuedefs

The queuedefs file defines how the system handles different cron daemon types. The file specifies the maximum number of processes per event type to schedule at one time, the nice value of the event type, and how long to wait before retrying to run a process. This file is empty as shipped, but can be modified to change how the cron daemon handles each event type. Each entry in the queuedefs file should be of the form:
           EventType.[Jobsj][Nicen][Waitw]
Refer to the man page on the queuedefs file for additional information.

cron.deny and at.deny

By default, any user can create jobs for the cron and at commands to run. In the /var/adm/cron directory are two files: cron.deny and at.deny. When installing, both are empty. If a cron.allow file exists in this directory, the user ID (including root) must be in the file before it can run cron jobs. For the at command, there is an at.allow file. If the .allow files do not exist, both cron and at look in the .deny files. If the user is not denied, the user may submit cron jobs.

For additional information about the cron, at, and crontab commands, see their respective man pages.

More about cron commands

Setting up a crontab entry

When logged in as the user doing the cron job, type the following command:
           crontab -e
This starts an editing session for the /var/spool/cron/crontabs/user_id file. By default, the vi editor is used. If the EDITOR environment variable is set, that editor is used.

Any lines beginning with a pound sign (#) are comments and are ignored.

A crontab entry consists of six fields:

The specification of days may be made by two fields (day of the month and day of the week). If you specify both as a list of elements, both are adhered to. For example:

           0 0 1,15 * 1 command
This entry would run command on the first and fifteenth days of each month, as well as every Monday. To specify days by only one field, the other field should contain an "*" (asterisk).

For example, to run the date command at 2 a.m. on Monday:

    0 2 * * 1 /bin/date
The parameters can also be specified as a range with a dash (-), as in 1-5, or a list separated by commas, as in 1,2,3,4,5. For more information on crontab entries, see the man page for the crontab command.

0481-086 and 0481-079 errors from the cron daemon

If you get errors from the cron daemon, do the following:

Listing crontab entries

The crontab -l command will list the cron jobs for the current user.

Ensuring cron is working

To ensure cron is working, do a simple test by entering the following command:
           * * * * * /bin/date
Then check your mail. cron sends the output from standard out and standard error to the mailbox of the user submitting the job. You should receive the output of the date command once each minute. If you do not get mail back, check to see if the cron daemon is running. Enter the following:
           ps -eaf |grep cron
Look for a line where the last field is: /usr/sbin/cron or /etc/cron. If cron is not running, check the /etc/inittab file for an entry such as the following:
           cron:2:respawn:/usr/sbin/cron
or
           cron:2:respawn:/etc/cron
If you have this entry and cron is still not running, execute:
           telinit q
Then recheck using the ps command above to see if cron is running. If this still does not work, contact your support organization for assistance.

crontab entry is changed but cron is not running

When you directly edit a file in the /var/spool/cron/crontabs directory, cron will never look at the new file unless you tell it to. The correct way to add or change a cron entry is to log in or su to the userID and then issue the crontab -e command. If you have manually edited one of the files, you must stop the cron daemon and let it respawn (restart). To stop the cron daemon, follow the steps below:
           ps -eaf |grep cron
The output will look something like the following:
           root  20294      1   0   Sep 26      -  4:18 /etc/cron
The number after root is the process ID (PID). Type kill -9 PID to stop cron and cause it to start and reread the crontabs files.

A job runs from the command line but not from cron

The cron command starts a subshell from the home directory. The default shell for cron commands is /usr/bin/bsh, unless you have entered #!/usr/bin/ksh as the first line of the script to define the specific shell for cron to run. The environment set up by cron starts with what is defined in the /etc/environment file. To establish the same environment you have when you log in, you can add something like the following to your cron script:
           #!/bin/ksh
           cd $HOME
           . .profile
This will only pick up the environment variables that are set in the .profile file. To completely duplicate your environment, from the command line run the env command and explicitly set all the variables in the cron script with:
           export VARIABLE_NAME=value
NOTE: For the Korn shell, other environment variables may be set in /etc/profile and, depending upon the setting of the ENV environment variable, the file pointed to the variable is also run. You may have to explicitly set all the variables you need in the cron script.

Getting crout* files in /tmp

The /tmp directory has a lot of files that look like:
           croutAxwAXAxBC8
These files are created as temporary files in /tmp when cron runs a job. When the job finishes, the crout file is usually removed. If the files are still there, the cron daemon is failing half way through the job and is getting respawned by init. Therefore the job in question never completes.

To locate the bad job, check the timestamp. Enter the following:

           ls -l crout*
Match the output to the entry in the crontabs file to which it belongs.

Sending and routing cron mail

Stopping cron from sending mail

By default, cron sends any output going to standard out or standard error to the userID invoked by the cron job. If you don't want mail sent to you, you can redirect standard out and standard error by entering:
           cron_job_file >/dev/null 2>&1
If you are running a script, you may have to individually redirect any commands inside the file that write to either standard error or standard out.

Routing cron mail to another user

To mail to another user, enter:
           cron_job_file | mail user_name
You may have to do this inside the script file to catch all occurrences of output.

cron mail not received

If you did not receive mail, test to see if cron is working. See the section in this document called "
Ensuring cron is working".

If cron is running and you can get the output by running the date command in the test, the program or script is probably not running. See the section in this document called "A job runs from the command line but not from cron".

If you can see the job is running but you get no mail, test to see if you can send mail to the user submitting the cron job.

If you can send mail, the command or script probably is not outputting anything to standard out or standard error, or it is redirecting it somewhere else.


More about the at command

Defining the at command

The at command reads from standard input the names of commands to be run at a later time and allows you to specify when the commands should be run. The at command follows the same rules with the .allow and .deny files as cron does.

Commands submitted by the at command are actually run by the cron command.

Submitting an at job

To schedule a job to run at a later time, you must specify a time to start the job. Specify the time by using either the -t Date flag or the Time, Day, and Increment parameters.

The Date variable to the -t flag is specified using the following format:

[[CC]YY]MMDDhhmm[.SS] The digits in the Date variable are defined as follows:

For more information on using the -t flag, refer to the at command man page.

The most common way to submit a job is:

           echo <command to execute> |at -t 950603220000
or
           echo <command to execute> |at now + 200 minutes
See the at command man page for a complete list of time, day, and increment parameters.



[ Doc Ref: 90605200014612     Publish Date: Oct. 20, 2000     4FAX Ref: 4925 ]