:: RootR ::  Hosting Order Map Login   Secure Inter-Network Operations  
 
CRONTAB(5) - phpMan

Command: man perldoc info search(apropos)  


CRONTAB(5)                             File Formats Manual                             CRONTAB(5)



NAME
       crontab - tables for driving cron

DESCRIPTION
       A crontab file contains instructions to the cron(8) daemon of the general form: ``run this
       command at this time on this date''.  Each user has their own crontab, and commands in any
       given  crontab will be executed as the user who owns the crontab.  Uucp and News will usu‐
       ally have their own crontabs, eliminating the need for explicitly running su(1) as part of
       a cron command.

       Blank  lines and leading spaces and tabs are ignored.  Lines whose first non-space charac‐
       ter is a hash-sign (#) are comments, and are ignored.  Note that comments are not  allowed
       on  the  same  line  as cron commands, since they will be taken to be part of the command.
       Similarly, comments are not allowed on the same line as environment variable settings.

       An active line in a crontab will be either an environment setting or a cron command.   The
       crontab  file  is  parsed from top to bottom, so any environment settings will affect only
       the cron commands below them in the file.  An environment setting is of the form,

           name = value

       where the spaces around the equal-sign (=) are optional, and  any  subsequent  non-leading
       spaces  in  value  will  be  part  of the value assigned to name.  The value string may be
       placed in quotes (single or double, but matching) to preserve leading or trailing  blanks.
       To define an empty variable, quotes must be used. The value string is not parsed for envi‐
       ronmental substitutions or replacement of variables, thus lines like

           PATH = $HOME/bin:$PATH

       will not work as you might expect. And neither will this work

           A=1
           B=2
           C=$A $B

       There will not be any subsitution for the defined variables in the last value.

       An alternative for setting up the commands path is using the fact that  many  shells  will
       treat the tilde(~) as substitution of $HOME, so if you use bash for your tasks you can use
       this:

            SHELL=/bin/bash
            PATH=~/bin:/usr/bin/:/bin

       Several environment variables are set up automatically by the cron(8)  daemon.   SHELL  is
       set  to  /bin/sh,  and LOGNAME and HOME are set from the /etc/passwd line of the crontab's
       owner. PATH is set to "/usr/bin:/bin".  HOME, SHELL, and PATH may be  overridden  by  set‐
       tings  in  the  crontab;  LOGNAME is the user that the job is running from, and may not be
       changed.

       (Another note: the LOGNAME variable is sometimes called USER on BSD systems...   on  these
       systems, USER will be set also.)

       In  addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if it has any reason
       to send mail as a result of running commands in ``this'' crontab.  If  MAILTO  is  defined
       (and  non-empty),  mail  is  sent to the user so named.  MAILTO may also be used to direct
       mail to multiple recipients by separating recipient users  with  a  comma.  If  MAILTO  is
       defined  but empty (MAILTO=""), no mail will be sent.  Otherwise mail is sent to the owner
       of the crontab.

       On the Debian GNU/Linux system, cron supports the pam_env module, and loads  the  environ‐
       ment  specified  by /etc/environment and /etc/security/pam_env.conf.  It also reads locale
       information from /etc/default/locale.  However, the PAM settings do NOT override the  set‐
       tings described above nor any settings in the crontab file itself. Note in particular that
       if you want a PATH other than "/usr/bin:/bin", you will need to  set  it  in  the  crontab
       file.

       By default, cron will send mail using the mail "Content-Type:" header of "text/plain" with
       the "charset=" parameter set to the charmap / codeset of the locale in which  crond(8)  is
       started  up  -  ie. either the default system locale, if no LC_* environment variables are
       set, or the locale specified by the LC_* environment variables ( see locale(7)).  You  can
       use  different  character encodings for mailed cron job output by setting the CONTENT_TYPE
       and CONTENT_TRANSFER_ENCODING variables in crontabs, to the correct  values  of  the  mail
       headers of those names.

       The format of a cron command is very much the V7 standard, with a number of upward-compat‐
       ible extensions.  Each line has five time and date fields, followed by a command, followed
       by  a  newline  character ('\n').  The system crontab (/etc/crontab) uses the same format,
       except that the username for the command is specified after the time and date  fields  and
       before  the  command. The fields may be separated by spaces or tabs. The maximum permitted
       length for the command field is 998 characters.

       Commands are executed by cron(8) when the minute, hour, and month of year fields match the
       current  time,  and when at least one of the two day fields (day of month, or day of week)
       match the current time (see ``Note'' below).  cron(8) examines  cron  entries  once  every
       minute.  The time and date fields are:

              field          allowed values
              -----          --------------
              minute         0-59
              hour           0-23
              day of month   1-31
              month          1-12 (or names, see below)
              day of week    0-7 (0 or 7 is Sun, or use names)

       A field may be an asterisk (*), which always stands for ``first-last''.

       Ranges of numbers are allowed.  Ranges are two numbers separated with a hyphen.  The spec‐
       ified range is inclusive.  For example, 8-11 for an ``hours'' entry specifies execution at
       hours 8, 9, 10 and 11.

       Lists are allowed.  A list is a set of numbers (or ranges) separated by commas.  Examples:
       ``1,2,5,9'', ``0-4,8-12''.

       Step values can be used in conjunction with ranges.  Following a range with  ``/<number>''
       specifies  skips  of the number's value through the range.  For example, ``0-23/2'' can be
       used in the hours field to specify command execution every other hour (the alternative  in
       the V7 standard is ``0,2,4,6,8,10,12,14,16,18,20,22'').  Steps are also permitted after an
       asterisk, so if you want to say ``every two hours'', just use ``*/2''.

       Names can also be used for the ``month'' and ``day of week'' fields.  Use the first  three
       letters  of  the  particular day or month (case doesn't matter).  Ranges or lists of names
       are not allowed.

       The ``sixth'' field (the rest of the line) specifies the command to be  run.   The  entire
       command  portion  of the line, up to a newline or % character, will be executed by /bin/sh
       or by the shell specified in the SHELL variable of the crontab file.  Percent-signs (%) in
       the  command,  unless escaped with backslash (\), will be changed into newline characters,
       and all data after the first % will be sent to the command as standard input. There is  no
       way to split a single command line onto multiple lines, like the shell's trailing "\".

       Note:  The day of a command's execution can be specified by two fields — day of month, and
       day of week.  If both fields are restricted (i.e., aren't *), the command will be run when
       either field matches the current time.  For example,
       ``30  4  1,15 * 5'' would cause a command to be run at 4:30 am on the 1st and 15th of each
       month, plus every Friday. One can, however, achieve the desired result by adding a test to
       the command (see the last example in EXAMPLE CRON FILE below).

       Instead of the first five fields, one of eight special strings may appear:

              string         meaning
              ------         -------
              @reboot        Run once, at startup.
              @yearly        Run once a year, "0 0 1 1 *".
              @annually      (same as @yearly)
              @monthly       Run once a month, "0 0 1 * *".
              @weekly        Run once a week, "0 0 * * 0".
              @daily         Run once a day, "0 0 * * *".
              @midnight      (same as @daily)
              @hourly        Run once an hour, "0 * * * *".

       Please  note  that  startup,  as far as @reboot is concerned, is the time when the cron(8)
       daemon startup.  In particular, it may be before some system daemons, or other facilities,
       were startup.  This is due to the boot order sequence of the machine.


EXAMPLE CRON FILE
       The following lists an example of a user crontab file.


       # use /bin/bash to run commands, instead of the default /bin/sh
       SHELL=/bin/bash
       # mail any output to `paul', no matter whose crontab this is
       MAILTO=paul
       #
       # run five minutes after midnight, every day
       5 0 * * *       $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
       # run at 2:15pm on the first of every month -- output mailed to paul
       15 14 1 * *     $HOME/bin/monthly
       # run at 10 pm on weekdays, annoy Joe
       0 22 * * 1-5    mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
       23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
       5 4 * * sun     echo "run at 5 after 4 every sunday"
       # Run on every second Saturday of the month
       0 4 8-14 * *    test $(date +\%u) -eq 6 && echo "2nd Saturday"

EXAMPLE SYSTEM CRON FILE
       The  following  lists  the content of a regular system-wide crontab file. Unlinke a user's
       crontab, this file has the username field, as used by /etc/crontab.

       # /etc/crontab: system-wide crontab
       # Unlike any other crontab you don't have to run the `crontab'
       # command to install the new version when you edit this file
       # and files in /etc/cron.d. These files also have username fields,
       # that none of the other crontabs do.

       SHELL=/bin/sh
       PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

       # m h dom mon dow usercommand
       17 * * * *  root  cd / && run-parts --report /etc/cron.hourly
       25 6 * * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
       47 6 * * 7  root  test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
       52 6 1 * *  root  test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
       #

SEE ALSO
       cron(8), crontab(1)

EXTENSIONS
       When specifying day of week, both day 0 and day 7 will be considered Sunday.  BSD and AT&T
       seem to disagree about this.

       Lists  and  ranges are allowed to co-exist in the same field.  "1-3,7-9" would be rejected
       by AT&T or BSD cron -- they want to see "1-3" or "7,8,9" ONLY.

       Ranges can include "steps", so "1-9/2" is the same as "1,3,5,7,9".

       Months or days of the week can be specified by name.

       Environment variables can be set in the crontab.  In BSD or AT&T, the  environment  handed
       to child processes is basically the one from /etc/rc.

       Command output is mailed to the crontab owner (BSD can't do this), can be mailed to a per‐
       son other than the crontab owner (SysV can't do this), or the feature can  be  turned  off
       and no mail will be sent at all (SysV can't do this either).

       All of the `@' commands that can appear in place of the first five fields are extensions.

LIMITATIONS
       The cron daemon runs with a defined timezone. It currently does not support per-user time‐
       zones. All the tasks: system's and user's will be run based on  the  configured  timezone.
       Even  if a user specifies the TZ environment variable in his crontab this will affect only
       the commands executed in the crontab, not the execution of the crontab tasks themselves.

       The crontab syntax does not make it possible to define  all  possible  periods  one  could
       image  off.  For example, it is not straightforward to define the last weekday of a month.
       If a task needs to be run in a specific period of time  that  cannot  be  defined  in  the
       crontab  syntaxs  the best approach would be to have the program itself check the date and
       time information and continue execution only if the period matches the desired one.

       If the program itself cannot do the checks then a wrapper script would be required. Useful
       tools that could be used for date analysis are ncal or calendar For example, to run a pro‐
       gram the last Saturday of every month you could use the following wrapper code:

       0 4 * * Sat   [ "$(date +\%e)" = "`ncal | grep $(date +\%a | sed -e 's/.$//') | sed -e 's/^.*\s\([0-9]\+\)\s*$/\1/'`" ] && echo "Last Saturday" && program_to_run



DIAGNOSTICS
       cron requires that each entry in a crontab end in a newline character. If the  last  entry
       in  a crontab is missing a newline (ie, terminated by EOF), cron will consider the crontab
       (at least partially) broken. A warning will be written to syslog.


AUTHOR
       Paul Vixie <paul AT vix.com> is the author of cron and original creator of this manual  page.
       This  page has also been modified for Debian by Steve Greenland, Javier Fernandez-Sanguino
       and Christian Kastner.



4th Berkeley Distribution                 19 April 2010                                CRONTAB(5)


rootr.net - man pages