unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

crontab(1)                       User Commands                      crontab(1)



NAME
       crontab - user crontab file

SYNOPSIS
       crontab [filename]

       crontab [-elr username]

DESCRIPTION
       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'
       crontabs.

       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
            /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  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
       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 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
       /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. 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.



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 -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

       This 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.

ENVIRONMENT VARIABLES
       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).



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
       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
       Interface StabilityStandard


SEE ALSO
       atq(1),   atrm(1),   auths(1),   sh(1),   vi(1),   cron(1M),    su(1M),
       auth_attr(4), attributes(5), environ(5), standards(5)

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.

       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)