cron(8) — Linux manual page

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | SIGNALS | CLUSTERING SUPPORT | CAVEATS | SEE ALSO | AUTHOR | COLOPHON

CRON(8)                   System Administration                  CRON(8)

NAME         top

       crond - daemon to execute scheduled commands

SYNOPSIS         top

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

DESCRIPTION         top

       Cron is started from /etc/rc.d/init.d or /etc/init.d when
       classical sysvinit scripts are used. In case systemd is enabled,
       then unit file is installed into
       /lib/systemd/system/crond.service and daemon is started by
       systemctl start crond.service command. It returns immediately,
       thus, there is no need to need to start it with the '&'
       parameter.

       Cron searches /var/spool/cron for crontab files which are named
       after accounts in /etc/passwd; The found crontabs are loaded into
       the memory.  Cron also searches for /etc/anacrontab and 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 the inotify support.  Using of inotify is logged
       in the /var/log/cron log after the daemon is started.  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.  Nowadays the file is empty by default.
              Originally it was usually used to run daily, weekly,
              monthly jobs.  By default these jobs are now run through
              anacron which reads /etc/anacrontab configuration file.
              See anacrontab(5) for more details.

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

       /var/spool/cron
              directory that contains user crontables created by the
              crontab command.

       Note that the crontab(1) command updates the modtime of the spool
       directory whenever it changes a crontab.

   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         top

       -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 (i.e., crond -m 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.

       -p     Allows Cron to accept any user set crontables.

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

SIGNALS         top

       When the SIGHUP is received, the Cron daemon will close and
       reopen its log file.  This proves to be useful in scripts which
       rotate and age log files.  Naturally, this is not relevant if
       Cron was built to use syslog(3).

CLUSTERING SUPPORT         top

       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         top

       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         top

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

AUTHOR         top

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

COLOPHON         top

       This page is part of the cronie (crond daemon) project.
       Information about the project can be found at 
       ⟨https://github.com/cronie-crond/cronie⟩.  If you have a bug
       report for this manual page, see
       ⟨https://github.com/cronie-crond/cronie/issues⟩.  This page was
       obtained from the project's upstream Git repository
       ⟨https://github.com/cronie-crond/cronie.git⟩ on 2021-04-01.  (At
       that time, the date of the most recent commit that was found in
       the repository was 2021-03-29.)  If you discover any rendering
       problems in this HTML version of the page, or you believe there
       is a better or more up-to-date source for the page, or you have
       corrections or improvements to the information in this COLOPHON
       (which is not part of the original manual page), send a mail to
       man-pages@man7.org

cronie                         2013-09-26                        CRON(8)

Pages that refer to this page: cronnext(1)crontab(1)pmfind_check(1)pmie_check(1)pmlogger_check(1)crontab(5)passwd(5)hier(7)keyrings(7)persistent-keyring(7)user-keyring(7)anacron(8)warnquota(8)