crond - daemon to execute scheduled commands
is started from /etc/rc.d/init.d
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 '&'
for crontab files which are named
after accounts in /etc/passwd;
The found crontabs are loaded into the
also searches for /etc/anacrontab
and any files in
directory, which have a different format (see
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
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.
checks these files and directories:
- 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
- directory that contains system cronjobs stored for
- directory that contains user crontables created by the
Note that the crontab(1)
command updates the modtime of the spool
directory whenever it changes a crontab.
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.
supports access control with PAM if the system has PAM installed.
For more information, see pam(8)
. A PAM configuration file for
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.
- Prints a help message and exits.
- Disables inotify support.
- 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.
- 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
- Allows Cron to accept any user set crontables.
- Don't set PATH. PATH is instead inherited from the
- This option enables clustering support, as described
- 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.
- This option allows you to set debug flags.
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
In this version of Cron
it is possible to use a network-mounted shared
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
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
file or on files in the /etc/cron.d
These files are always run and considered host-specific.
Rather than editing /var/spool/cron/.cron.hostname
directly, use the
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.
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
The syslog output will be used instead of mail, when sendmail is not installed.