Tribblix: manual page: crontab.1

CRONTAB(1) User Commands CRONTAB(1)

NAME

crontab - user crontab file

SYNOPSIS

/usr/bin/crontab [-u username] [filename]

/usr/bin/crontab { -e | -l | -r } [username]

/usr/bin/crontab -u username { -e | -l | -r }

/usr/xpg4/bin/crontab [filename]

/usr/xpg4/bin/crontab { -e | -l | -r } [username]

/usr/xpg4/bin/crontab -u username { -e | -l | -r }

/usr/xpg6/bin/crontab [filename]

/usr/xpg6/bin/crontab { -e | -l | -r } [username]

/usr/xpg6/bin/crontab -u username { -e | -l | -r }

DESCRIPTION

The crontab utility manages a user's access with cron (see cron(8))
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'
crontabs.

If crontab is invoked with filename, this overwrites an existing
crontab entry for the user that invokes it, or for the user specified
with the -u option.

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 /etc/cron.d/cron.deny.

o if neither file exists, only a user with the
solaris.jobs.user authorization is allowed to submit a
job.

o if Auditing 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 exist.

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:

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 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 hyphen (meaning an
inclusive range).

A range or asterisk can optionally be followed by a step value as
/<number>. For example, 2-59/3 can be used in the minutes field to
specify every three minutes starting at 2 past the hour, or */2 in
the hours field means every two hours.

Time specified here is interpreted in the currently active timezone.
At the top of the crontab file this is the timezone which is set
system-wide in /etc/default/init. A user can add a line such as:

TZ=timezone

...and all subsequent entries will be interpreted using that
timezone, until a new TZ=timezone line is encountered. 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
executed 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. As with $TZ, both
$SHELL and $HOME can be set by having a line such as:

SHELL=/usr/bin/someshell

...or:

HOME=somedirectory

...which will take precedence for all the remaining entries in the
crontab or until there is another HOME or SHELL entry. It is invoked
with an arg0 of the basename of the $SHELL that is currently in
effect. A user who wants to have his .profile or equivalent file
executed must explicitly do so in the crontab file. cron supplies a
default environment for every shell, defining HOME, LOGNAME, SHELL,
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(8)). The TZ, HOME, and SHELL
environment variables are set to match those that are in effect in
the crontab file at the time.

If you do not redirect the standard output and standard error of your
commands, any generated output or errors are mailed to you.

crontab Environment Variables
The following variables are supported:

HOME

Allows the user to choose an alternative directory for cron to
change directory to prior to running the command. For example:

HOME=/var/tmp

SHELL

The name of the shell to use to run subsequent commands. For
example:

SHELL=/usr/bin/ksh

TZ

Allows the user to choose the timezone in which the cron entries
are run. This effects both the environment of the command that
is run and the timing of the entry. For example, to have your
entries run using the timezone for Iceland, use:

TZ=Iceland

RANDOM_DELAY

Allows the user to specify an upper bound in minutes for which
execution may be delayed. The default is 0 which means no delay.
A value that is larger than the scheduled interval may result in
the command running less often. For example, to have the command
run at some random time within two minutes after the schedule
use:

RANDOM_DELAY=2

Each of these variables affects all of the lines that follow it in
the crontab file, until it is reset by a subsequent line resetting
that variable. Hence, it is possible to have multiple timezones
supported within a single crontab file.

The lines that are not setting these environment variables are the
same as crontab entries that conform to the UNIX standard and are
described elsewhere in this man page.

Setting cron Jobs Across Timezones
The default timezone of the cron daemon sets the system-wide timezone
for cron entries. This, in turn, is by set by default system-wide
using /etc/default/init.

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.

OPTIONS

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.

The environment variable EDITOR determines which editor is
invoked with the -e option. 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.

If username is specified, the specified user's crontab file is
edited, rather than the current user's crontab file. This can
only be done by root or by a user with the solaris.jobs.admin
authorization.

-l
Lists the crontab file for the invoking user. Only root or a
user with the solaris.jobs.admin authorization can specify a
username following the -l option to list the crontab file of
the specified user.

-r
Removes a user's crontab from the crontab directory. Only root
or a user with the solaris.jobs.admin authorization can specify
a username following the -r option to remove the crontab file
of the specified user.

-u username
Specifies the name of the user whose crontab is to be replaced,
viewed or modified. This can only be done by root or by a user
with the solaris.jobs.admin authorization.

EXAMPLES

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 -namecore 2>/dev/null | xargs rm -f

Example 2: Mailing a Birthday Greeting

This example mails a birthday greeting:

0 12 14 2 * mailx john%Happy Birthday!%Time for lunch.

Example 3: Specifying Days of the Month and Week

This example runs a command on the first and fifteenth of each month,
as well as on every Monday:

0 0 1,15 * 1

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.

Example 4: Using step values:

This example runs a job every hour during the night and every 3 hours
during working hours.

0 8-18/3,19-7 * * *

and to run a job every 2 minutes, use:

*/2 * * * *

Example 5: Using Environment Variables

The following entries take advantage of crontab support for certain
environment variables.

TZ=GMT
HOME=/local/home/user
SHELL=/usr/bin/ksh
0 0 * * * echo $(date) > midnight.GMT
TZ=PST
0 0 * * * echo $(date) > midnight.PST
TZ=EST
HOME=/local/home/myuser
SHELL=/bin/csh

The preceding entries allow two jobs to run. The first one would run
at midnight in the GMT timezone and the second would run at midnight
in the PST timezone. Both would be run in the directory
/local/home/user using the Korn shell. The file concludes with TZ,
HOME, and SHELL entries that return those variable to their default
values.

ENVIRONMENT VARIABLES

See environ(7) for descriptions of the following environment
variables that affect the execution of crontab: LANG, LC_ALL,
LC_CTYPE, LC_MESSAGES, and NLSPATH.

/usr/bin/crontab
EDITOR
Determine the editor to be invoked when the -e option is
specified. This is overridden by the VISUAL environmental
variable. The default editor is vi(1).

PATH
The PATH in crontab's environment specifies the search path
used to find the editor.

VISUAL
Determine the visual editor to be invoked when the -e
option is specified. If VISUAL is not specified, then the
environment variable EDITOR is used. If that is not set,
the default is vi(1).

/usr/xpg4/bin/crontab
EDITOR
Determine the editor to be invoked when the -e option is
specified. The default editor is /usr/xpg4/bin/vi.

/usr/xpg6/bin/crontab
EDITOR
Determine the editor to be invoked when the -e option is
specified. The default editor is /usr/xpg6/bin/vi.

EXIT STATUS

The following exit values are returned:

0
Successful completion.

>0
An error occurred.

FILES

/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

ATTRIBUTES

NOTES

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.

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.

If an authorized user other than root modifies another user's crontab
file, the resulting behavior can be unpredictable. Instead, the
authorized user should first use su(8) to become superuser to the
other user's login before making any changes to the crontab file.

Care should be taken when adding TZ, SHELL and HOME variables to the
crontab file when the crontab file could be shared with applications
that do not expect those variables to be changed from the default.
Resetting the values to their defaults at the bottom of the file will
minimize the risk of problems.

January 9, 2022 CRONTAB(1)