Answer

This document describes how the cron and at commands work and applies to AIX Versions 4 and 5.

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
What shell do cron jobs run?
More about the at command
    Defining the at command
    Submitting an at job

---

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 minute (0 through 59)
• The hour (0 through 23)
• The day of the month (1 through 31)
• The month of the year (1 through 12)
• The day of the week (0 through 6 for Sunday through Saturday)
• The command to run

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:

• Make sure the crontab file does not contain any blank lines, including at the end of the file. The file CANNOT contain any blank lines.

• Check each line and ensure that the syntax is correct. Test by commenting out an entry (using # at the beginning of the line) until you find the invalid line.

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.

NOTE: It is not supported to run interactive scripts out of cron or those that might require input from a user to continue.

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.

---

What shell do cron jobs run?

Cron jobs run in the shell specified for the user in /etc/passwd, unless it is specified different within the script. Prior to AIX 4.1.5.2, the Bourne shell was the default shell when creating a user. Since then, the korn shell is the default shell. If the user is using korn shell, there is no need to specify #!/bin/ksh at the beginning of the script.

---

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.

• The at command is only used to submit jobs.

• The at command mails the output from standard out and standard error back to the user submitting the job.

• Unlike cron, the at command preserves the current environment, including the userID and current directory.

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:

• CC specifies the first two digits of the year (the century).

• YY specifies the second two digits of the year.

• MM specifies the month of the year (01 through 12).

• DD specifies the day of the month (01 through 31).

• hh specifies the hour of the day (00 through 23).

• mm specifies the minute of the hour (00 through 59).

• SS specifies the second of the minute (00 through 59).

• Both the CC and YY digits are optional. If neither is given, the current year is assumed.

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.

---

APARs related to cron and at

All APARs and PTFs related to cron and at issues are found in the bos.rte.cron fileset. Here is a list of the current fixes as of 12/31/04:

bos.rte.cron 5.1.0.25
IY27024 U477276 (S) 356618    SysV Affinity : atrm Command
IY27934 U477276 (S) 358376    cron fills up /var when nice value for batch jobs 
is 2
IY27948 U477276 (S) 354472    null crontabs observed on machines
bos.rte.cron 5.1.0.35
IY33527 U483239 (S) 376103    crontab returns wrong exit status
 
bos.rte.cron 5.1.0.36
IY35284 U486102 (S) 385368    at command: problems with zulu option 
 
bos.rte.cron 5.1.0.50
IY35284 U485280 (S) 385368    at command: problems with zulu option 
IY38564 U485280 (S) 389262    at should report error when incorrect date format 
is given
 
bos.rte.cron 5.1.0.51
IY43778 U487695 (S) 400977    cronadm cron -l command fails with an error 
message
 
bos.rte.cron 5.1.0.52
IY47344 U489627 (S) 409380    Command at returns 0481-103 error
 
bos.rte.cron 5.1.0.53
IY46416 U495828 (S) 410935    Unable to match job name to pid in cron logfile
 
bos.rte.cron 5.1.0.54
IY54789 U496960 (S) 430559    Cron misses jobs immediately after DST changes 
(3:01 am)
 
bos.rte.cron 5.2.0.1
IY37677 U486750 (S) 385368    at command: problems with zulu option 
 
bos.rte.cron 5.2.0.10
IY37677 U485455 (S) 385368    at command: problems with zulu option 
IY39197 U485455 (S) 389262    at should report error when incorrect date format 
is given
 
bos.rte.cron 5.2.0.11
IY44162 U486461 (S) 400977    cronadm cron -l command fails with an error 
message
 
bos.rte.cron 5.2.0.12
IY46830 U489877 (S) 409380    Command at returns 0481-103 error
 
bos.rte.cron 5.2.0.13
IY48821 U495403 (S) 410935    Unable to match job name to pid in cron logfile
 
bos.rte.cron 5.2.0.30
IY44162 U488963 (S) 400977    cronadm cron -l command fails with an error 
message
IY46830 U488963 (S) 409380    Command at returns 0481-103 error
IY48821 U488963 (S) 410935    Unable to match job name to pid in cron logfile
IY53638 U488963 (S) 430559    Cron misses jobs immediately after DST changes 
(3:01 am)
 
bos.rte.cron 5.3.0.1
IY60689 U499937 (S) 469289    Deletion of all jobs fails for root user
 
bos.rte.cron 5.3.0.10
IY60689 U800040 (S) 469289    Deletion of all jobs fails for root user

NOTE: Fixes can be downloaded from Fix Central (http://www-912.ibm.com/eserver/support/fixes/fcgui.jsp).