crontab(1) DG/UX R4.11MU05 crontab(1)
NAME
crontab - install user crontab file
SYNOPSIS
crontab [file]
crontab -e [ username ]
crontab -r [ username ]
crontab -l [ username ]
DESCRIPTION
crontab copies the specified file, or standard input if no file is
specified, into a directory that holds all users' crontabs. The -e
option edits a copy of the current user's crontab file, or creates an
empty file to edit if crontab does not exist. When editing is
complete, the file is installed as the user's crontab file. If a
username is given, the specified user's crontab file is edited,
rather than the current user's crontab file; this may only be done by
a user with the appropriate privilege. The environment variable
EDITOR determines which editor is invoked with the -e option. The
default editor is ed(1). One note of caution, if you plan to remove
all of the entries from a crontab file, use the -r option described
next. The -r option removes a user's crontab from the crontab
directory. crontab -l will list the crontab file for the invoking
user. Only a user with the appropriate privilege can specify a
username following the -r or -l options to remove or list the crontab
file of the specified user.
For systems supporting the DG/UX Capability Option, appropriate
privilege is defined as having one or more specific capabilities
enabled in the effective capability set of the user. See
capdefaults(5) for the default capabilities for this command.
On systems without the DG/UX Capability Option, appropriate privilege
means that your process has an effective UID of root. See the
appropriateprivilege(5) man page for more information.
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 root 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.
Security Features
On a system with DG/UX information security, the cron daemon is a
full-fledged session initiator. This means that the submitted job
must be authorized to run at the time for which it is scheduled. This
determination is made by the cron daemon at run time. Therefore, it
is no longer safe to assume that the job will be run simply because
crontab accepted the job when invoked by the user (per the access
restrictions described above). For a job created by crontab, cron
will attempt to create the session via credentiald with a service
name of "crontab", the username of the submitting user, and the time
at which the job is scheduled to run. On systems with mandatory
access control (MAC), the label at which the job was submitted is
also requested for the new session. If the job turns out not to be
authorized, cron will send mail to the user reporting this. The
credentials of the job when it runs are determined by merging those
of the submitting user (saved by crontab for retrieval by cron) and
those authorized for the session by credentiald. This is done in a
restrictive way (the merge intersects features of the credentials
which grant privilege (such as capabilities) while unioning those
which limit privilege (audit mask)).
On a system with DG/UX information security, the spool area,
/var/spool/cron/crontabs, is a multilevel directory. All jobs
submitted by crontab will be run at the MAC label of the submitting
process. This means that a user may have several different sets of
jobs submitted to cron by crontab, if each of them is submitted at a
different MAC label.
When the -r option is used on a system with DG/UX information
security, the crontab will only be removed at the current process
clearance label. This command must be issued at each clearance level
where a crontab is active.
Crontab Format
A crontab file consists of lines of six fields each. The fields are
separated by spaces or tabs. The first five are integer patterns
that specify the following:
minute (0-59),
hour (0-23),
day of the month (1-31),
month of the year (1-12),
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 (meaning an
inclusive range). Note that the specification of days may be made by
two fields (day of the month and day of the week). If both are
specified as a list of elements, both are adhered to. For example, 0
0 1,15 * 1 would run a command on the first and fifteenth of each
month, as well as on every Monday. To specify days by only one
field, the other field should be set to * (for example, 0 0 * * 1
would run a command only on Mondays).
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. Only the first line (up to a % or end of line) of
the command field is executed by the shell. The other lines are made
available to the command as standard input.
To have cron execute more than one command in a single given crontab
line, separate the comands in the sixth field by semicolons (see
example).
Any line beginning with a # is a comment and will be ignored.
The shell is invoked from your $HOME directory with an arg0 of sh.
Users who desire to have their .profile executed must explicitly do
so in the crontab file. cron supplies a default environment for
every shell, defining HOME, LOGNAME, SHELL (=/bin/sh), and PATH
(=:/bin:/usr/bin:/usr/lbin).
To redirect the standard output of a command to a file foo, append
>foo to the command in the crontab file. To redirect standard error
of a command to a file foo, append 2>foo to the command in the
crontab file (see examples).
If you do not redirect the standard output and standard error of your
commands, any generated output or errors will be mailed to you.
EXAMPLES
The following are examples of valid crontab file lines:
39 15 * * * date "+job1 run at \%H:\%M:\%S"%
Causes the command date "+job1 run at %H:%M:%S" to be executed each
day at 3:39 pm.
30 1 10 6 * echo "abc" 1>/dev/null%
Causes abc to be written to file /dev/null each year on June 10 at
1:30 am.
15 14 * * 0 xyzabc 2>/dev/null%
Executes the command xyzabc every Sunday at 2:15 pm and writes any
errors to the file /dev/null.
0 9 * * * command1 ; command2%
Causes both command1 and command2 to be executed at 9:00 every
morning.
FILES
/etc/cron.d main cron directory
/var/spool/cron/crontabs spool area
/var/cron/log accounting information
/etc/cron.d/cron.allow list of allowed users
/etc/cron.d/cron.deny list of denied users
SEE ALSO
atq(1), atrm(1), credentiald(1), sh(1), su(1), ed(1), cron(1M),
appropriateprivilege(5).
capdefaults(5).
NOTES
If you inadvertently enter the crontab command with no argument(s),
do not attempt to get out with a Ctrl-D. This will cause all entries
in your crontab file to be removed. Instead, exit with a DEL.
If a user with the appropriate privilege modifies another user's
crontab file, resulting behavior may be unpredictable. Instead, the
privileged user should first su(1) to the other user's login before
making any changes to the crontab file.
When using crontab with the -e option, if the invoked editor returns
a non-zero status code, crontab will give the user the opportunity to
re-edit the crontab file or abort the edit. One situation where this
might happen would be, when using vi(1), deleting the last lines from
the editor's buffer. This would cause vi to return a non-zero status
when exited.
The string, #ACCOUNTING#, should only be used in the root crontab
file in lines associated with accounting cron jobs. Use of the
string #ACCOUNTING#, with non-accounting cron jobs can lead to
removal of non-accounting cron jobs from the crontab.
Licensed material--property of copyright holder(s)