crontab(1) User Commands crontab(1)
crontab - user crontab file
crontab [-elr username]
The crontab utility manages a user's access with cron (see cron(1M)) by
copying, creating, listing, and removing crontab files. If invoked
without options, crontab copies the specified file, or the standard
input if no file is specified, into a directory that holds all users'
If crontab is invoked with filename, this overwrites an existing
crontab entry for the user that invokes it.
crontab Access Control
Users: Access to crontab is allowed:
o if the user's name appears in /etc/cron.d/cron.allow.
o if /etc/cron.d/cron.allow does not exist and the user's name is
not in /etc/cron.d/cron.deny.
Users: Access to crontab is denied:
o if /etc/cron.d/cron.allow exists and the user's name is not in it.
o if /etc/cron.d/cron.allow does not exist and user's name is in
o if neither file exists, only a user with the solaris.jobs.user
authorization is allowed to submit a job.
o if BSM audit is enabled, the user's shell is not audited and the
user is not the crontab owner. This can occur if the user logs in
by way of a program, such as some versions of SSH, which does not
set audit parameters.
The rules for allow and deny apply to root only if the allow/deny files
The allow/deny files consist of one user name per line.
crontab Entry 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:
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 can 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). Time specified here is interpreted in the timezone of the
cron(1M) daemon, which is set system-wide in /etc/default/init. Entries
do not use the invoking user's timezone. The specification of days can
be made by two fields (day of the month and day of the week). Both are
adhered to if specified as a list of elements. See EXAMPLES.
The sixth field of a line in a crontab file is a string that is exe-
cuted by the shell at the specified times. A percent character in this
field (unless escaped by \) is translated to a NEWLINE character.
Only the first line (up to a `%' or end of line) of the command field
is executed by the shell. Other lines are made available to the command
as standard input. Any blank line or line beginning with a `#' is a
comment and is 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), TZ, and PATH. The
default PATH for user cron jobs is /usr/bin; while root cron jobs
default to /usr/sbin:/usr/bin. The default PATH can be set in
/etc/default/cron (see cron(1M)).
If you do not redirect the standard output and standard error of your
commands, any generated output or errors are mailed to you.
Setting cron Jobs Across Timezones
The timezone of the cron daemon sets the system-wide timezone for cron
entries. This, in turn, is by set by default system-wide using
If some form of daylight savings or summer/winter time is in effect,
then jobs scheduled during the switchover period could be executed
once, twice, or not at all.
The following options are supported:
-e 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 can
only be done by a user with the solaris.jobs.admin authoriza-
tion. The environment variable EDITOR determines which editor
is invoked with the -e option. The default editor is ed(1).
All crontab jobs should be submitted using crontab. Do not add
jobs by just editing the crontab file, because cron is not
aware of changes made this way.
If all lines in the crontab file are deleted, the old crontab
file is restored. The correct way to delete all lines is to
remove the crontab file using the -r option.
-l Lists the crontab file for the invoking user. Only a user with
the solaris.jobs.admin authorization can specify a username
following the -r or -l options to remove or list the crontab
file of the specified user.
-r Removes a user's crontab from the crontab directory.
Example 1: Cleaning up Core Files
This example cleans up core files every weekday morning at 3:15 am:
15 3 * * 1-5 find $HOME -name core 2>/dev/null | xargs rm -f
Example 2: Mailing a Birthday Greeting
0 12 14 2 * mailx john%Happy Birthday!%Time for lunch.
Example 3: Specifying Days of the Month and Week
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 *.
0 0 * * 1
would run a command only on Mondays.
See environ(5) for descriptions of the following environment variables
that affect the execution of crontab: LANG, LC_ALL, LC_CTYPE, LC_MES-
SAGES, and NLSPATH.
EDITOR Determine the editor to be invoked when the -e option
is specified. The default editor is vi(1).
The following exit values are returned:
0 Successful completion.
>>0 An error occurred.
/etc/cron.d main cron directory
/etc/cron.d/cron.allow list of allowed users
/etc/default/cron contains cron default settings
/etc/cron.d/cron.deny list of denied users
/var/cron/log accounting information
/var/spool/cron/crontabs spool area for crontab
See attributes(5) for descriptions of the following attributes:
tab() allbox; cw(2.750000i)| cw(2.750000i) lw(2.750000i)|
lw(2.750000i). ATTRIBUTE TYPEATTRIBUTE VALUE AvailabilitySUNWcsu
atq(1), atrm(1), auths(1), sh(1), vi(1), cron(1M), su(1M),
auth_attr(4), attributes(5), environ(5), standards(5)
If you inadvertently enter the crontab command with no arguments, do
not attempt to get out with Control-d. This removes all entries in your
crontab file. Instead, exit with Control-c.
If an authorized user modifies another user's crontab file, resulting
behavior can be unpredictable. Instead, the super-user should first use
su(1M) to become super-user to the other user's login before making any
changes to the crontab file.
When updating cron, check first for existing crontab entries that can
be scheduled close to the time of the update. Such entries can be lost
if the update process completes after the scheduled event. This can
happen because, when cron is notified by crontab to update the internal
view of a user's crontab file, it first removes the user's existing
internal crontab and any internal scheduled events. Then it reads the
new crontab file and rebuilds the internal crontab and events. This
last step takes time, especially with a large crontab file, and can
complete after an existing crontab entry is scheduled to run if it is
scheduled too close to the update. To be safe, start a new job at least
60 seconds after the current date and time.
SunOS 5.10 7 May 2004 crontab(1)