Ubuntu Manpage: crond - daemon to execute scheduled commands

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.

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⟩