NAME
crond - daemon to execute scheduled commands
SYNOPSIS
crond [-n | -p | -s | -c | -m<mailcommand>]
crond -x [ext,sch,proc,pars,load,misc,test,bit]
DESCRIPTION
Cron is started from /etc/rc.d/init.d or /etc/init.d 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/anacrontab system
crontab, usually used to run daily, weekly, monthly jobs. 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
-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.
-p Allows Cron to accept any user set crontables.
-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.
SIGNALS
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
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 <c.c.dean@durham.ac.uk>