NAME

       crond - daemon to execute scheduled commands

SYNOPSIS

       crond [-c | -h | -i | -n | -p | -P | -s | -m<mailcommand>]
       crond -x [ext,sch,proc,pars,load,misc,test,bit]
       crond -V

DESCRIPTION

       Cron is automatically started at boot time.

       Cron  searches  /var/spool/cron/crontabs  for  crontab  files  which  are named after user
       accounts; together with the system crontab /etc/crontab, the  found  crontabs  are  loaded
       into  the  memory.   Cron  also searches for any files in the /etc/cron.d directory, which
       have a different format (see crontab(5)).  Cron examines all stored  crontabs  and  checks
       each job to see if it needs to be run in the current minute.  When executing commands, any
       output is mailed to the owner of the crontab (or to  the  user  specified  in  the  MAILTO
       environment  variable in the crontab, if such exists).  Any job output can also be sent to
       syslog by using the -s option.

       There are two ways how changes in crontables are checked.  The first  method  is  checking
       the modtime of a file. The second method is using inotify support, which is only available
       on Linux.  When the daemon uses inotify, it logs this fact  to  syslog  on  startup.   The
       inotify  support checks for changes in all crontables and accesses the hard disk only when
       a change is detected.

       When using the modtime option, Cron checks its crontables' modtimes every minute to  check
       for  any  changes  and  reloads  the  crontables  which have changed.  There is no need to
       restart Cron after some of the crontables were modified.  The modtime option is also  used
       when inotify can not be initialized.

       Cron checks these files and directories:

       /etc/crontab
              system crontab, usually used to run daily, weekly, monthly jobs. See crontab(5) for
              more details.

       /etc/cron.d/
              directory that contains system cronjobs stored for different users.

       /var/spool/cron/crontabs
              directory that contains user crontables created by the crontab(1) command.

   Daylight Saving Time and other time changes
       Local time changes of less than three hours, such as those caused by the  Daylight  Saving
       Time  changes,  are  handled  in  a  special way.  This only applies to jobs that run at a
       specific time and jobs that run with a granularity greater than one hour.  Jobs  that  run
       more frequently are scheduled normally.

       If time was adjusted one hour forward, those jobs that would have run in the interval that
       has been skipped will be run immediately.  Conversely,  if  time  was  adjusted  backward,
       running the same job twice is avoided.

       Time  changes  of  more  than 3 hours are considered to be corrections to the clock or the
       timezone, and the new time is used immediately.

       It is possible to use different time  zones  for  crontables.   See  crontab(5)  for  more
       information.

   PAM Access Control
       Cron  supports  access  control  with  PAM  if  the  system  has  PAM installed.  For more
       information,  see  pam(8).   A  PAM  configuration  file  for  crond   is   installed   in
       /etc/pam.d/crond.  The daemon loads the PAM environment from the pam_env module.  This can
       be overridden by defining specific settings in the appropriate crontab file.

OPTIONS

       -h     Prints a help message and exits.

       -i     Disables inotify support.

       -m     This option allows you to specify a shell command to  use  for  sending  Cron  mail
              output instead of using sendmail(8) This command must accept a fully formatted mail
              message (with headers) on standard input and send it  as  a  mail  message  to  the
              recipients  specified  in the mail headers.  Specifying the string off will disable
              the sending of mail.

       -n     Tells the daemon to run in the foreground.  This can be useful when starting it out
              of  init.  With this option is needed to change pam setting.  /etc/pam.d/crond must
              not enable pam_loginuid.so module.

       -f     the same as -n, consistent with other crond implementations.

       -i     Disables inotify support (if present)

       -p     Allows Cron to accept any user set crontables (read:  lift  owner,  type  and  mode
              restrictions)

       -P     Don't set PATH.  PATH is instead inherited from the environment.

       -c     This option enables clustering support, as described below.

       -s     This  option  will  direct  Cron  to  send  the  job output to the system log using
              syslog(3).  This is useful if your system does not have sendmail(8),  installed  or
              if mail is disabled.

       -x     This option allows you to set debug flags.

       -V     Print version and exit.

CLUSTERING SUPPORT

       In  this  version  of  Cron it is possible to use a network-mounted shared /var/spool/cron
       across a cluster of hosts and specify that only one of the hosts should  run  the  crontab
       jobs in this directory at any one time.  This is done by starting Cron with the -c option,
       and have the /var/spool/cron/.cron.hostname file contain just one line,  which  represents
       the  hostname of whichever host in the cluster should run the jobs.  If this file does not
       exist, or the hostname in it does not match that  returned  by  gethostname(2),  then  all
       crontab files in this directory are ignored.  This has no effect on cron jobs specified in
       the /etc/crontab file or on files in the /etc/cron.d directory.  These  files  are  always
       run and considered host-specific.

       Rather  than  editing  /var/spool/cron/.cron.hostname  directly,  use  the  -n  option  of
       crontab(1) to specify the host.

       You should ensure that all hosts in a cluster, and the file server from which  they  mount
       the  shared  crontab  directory,  have  closely  synchronised clocks, e.g., using ntpd(8),
       otherwise the results will be very unpredictable.

       Using cluster sharing automatically disables inotify support, because  inotify  cannot  be
       relied on with network-mounted shared file systems.

CAVEATS

       All  crontab files have to be regular files or symlinks to regular files, they must not be
       executable or writable for anyone else but the owner.  This requirement can be  overridden
       by  using  the -p option on the crond command line.  If inotify support is in use, changes
       in the symlinked crontabs are not automatically noticed by  the  cron  daemon.   The  cron
       daemon  must  receive a SIGHUP signal to reload the crontabs.  This is a limitation of the
       inotify API.

       The syslog output will be used instead of mail, when sendmail is not installed.

SEE ALSO

       crontab(1), crontab(5), inotify(7), pam(8)

AUTHOR

       Paul Vixie ⟨vixie@isc.org⟩
       Marcela Mašláňová ⟨mmaslano@redhat.com⟩
       Colin Dean ⟨colin@colin-dean.org⟩
       Tomáš Mráz ⟨tmraz@fedoraproject.org⟩