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.
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
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
EventType.[Jobsj][Nicen][Waitw]
Refer to the man page on the queuedefs file for additional
information.
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.
* * * * * /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.
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.
#!/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.
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.
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.
cron_job_file | mail user_name
You may have to do this inside the script file to catch all
occurrences of output.
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.
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.
Commands submitted by the at command are actually run by the cron command.
The Date variable to the -t flag is specified using the following format:
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: Nov. 07, 2001]