1CRON(8) System Administration CRON(8)
2
6 crond - daemon to execute scheduled commands
7
9 crond [-c | -h | -i | -n | -p | -P | -s | -m<mailcommand>]
10 crond -x [ext,sch,proc,pars,load,misc,test,bit]
11 crond -V
12
14 Cron is started from /etc/rc.d/init.d or /etc/init.d when classical
15 sysvinit scripts are used. In case systemd is enabled, then unit file
16 is installed into /lib/systemd/system/crond.service and daemon is
17 started by systemctl start crond.service command. It returns immedi‐
18 ately, thus, there is no need to need to start it with the '&' parame‐
19 ter.
20 Cron searches /var/spool/cron for crontab files which are named after
22 accounts in /etc/passwd; The found crontabs are loaded into the memory.
23 Cron also searches for /etc/anacrontab and any files in the /etc/cron.d
24 directory, which have a different format (see crontab(5)). Cron exam‐
25 ines all stored crontabs and checks each job to see if it needs to be
26 run in the current minute. When executing commands, any output is
27 mailed to the owner of the crontab (or to the user specified in the
28 MAILTO environment variable in the crontab, if such exists). Any job
29 output can also be sent to syslog by using the -s option.
30 There are two ways how changes in crontables are checked. The first
32 method is checking the modtime of a file. The second method is using
33 the inotify support. Using of inotify is logged in the /var/log/cron
34 log after the daemon is started. The inotify support checks for
35 changes in all crontables and accesses the hard disk only when a change
36 is detected.
37 When using the modtime option, Cron checks its crontables' modtimes ev‐
39 ery minute to check for any changes and reloads the crontables which
40 have changed. There is no need to restart Cron after some of the
41 crontables were modified. The modtime option is also used when inotify
42 can not be initialized.
43 Cron checks these files and directories:
45 /etc/crontab
47 system crontab. Nowadays the file is empty by default. Origi‐
48 nally it was usually used to run daily, weekly, monthly jobs.
49 By default these jobs are now run through anacron which reads
50 /etc/anacrontab configuration file. See anacrontab(5) for more
51 details.
52 /etc/cron.d/
54 directory that contains system cronjobs stored for different
55 users.
56 /var/spool/cron
58 directory that contains user crontables created by the crontab
59 command.
60 Note that the crontab(1) command updates the modtime of the spool di‐
62 rectory whenever it changes a crontab.
63 Daylight Saving Time and other time changes
65 Local time changes of less than three hours, such as those caused by
66 the Daylight Saving Time changes, are handled in a special way. This
67 only applies to jobs that run at a specific time and jobs that run with
68 a granularity greater than one hour. Jobs that run more frequently are
69 scheduled normally.
70 If time was adjusted one hour forward, those jobs that would have run
72 in the interval that has been skipped will be run immediately. Con‐
73 versely, if time was adjusted backward, running the same job twice is
74 avoided.
75 Time changes of more than 3 hours are considered to be corrections to
77 the clock or the timezone, and the new time is used immediately.
78 It is possible to use different time zones for crontables. See
80 crontab(5) for more information.
81 PAM Access Control
83 Cron supports access control with PAM if the system has PAM installed.
84 For more information, see pam(8). A PAM configuration file for crond
85 is installed in /etc/pam.d/crond. The daemon loads the PAM environment
86 from the pam_env module. This can be overridden by defining specific
87 settings in the appropriate crontab file.
88
90 -h Prints a help message and exits.
91 -i Disables inotify support.
93 -m This option allows you to specify a shell command to use for
95 sending Cron mail output instead of using sendmail(8) This com‐
96 mand must accept a fully formatted mail message (with headers)
97 on standard input and send it as a mail message to the recipi‐
98 ents specified in the mail headers. Specifying the string off
99 (i.e., crond -m off) will disable the sending of mail.
100 -n Tells the daemon to run in the foreground. This can be useful
102 when starting it out of init. With this option is needed to
103 change pam setting. /etc/pam.d/crond must not enable
104 pam_loginuid.so module.
105 -f the same as -n, consistent with other crond implementations.
107 -p Allows Cron to accept any user set crontables.
109 -P Don't set PATH. PATH is instead inherited from the environment.
111 -c This option enables clustering support, as described below.
113 -s This option will direct Cron to send the job output to the sys‐
115 tem log using syslog(3). This is useful if your system does not
116 have sendmail(8), installed or if mail is disabled.
117 -x This option allows you to set debug flags.
119 -V Print version and exit.
121
123 When the SIGHUP is received, the Cron daemon will close and reopen its
124 log file. This proves to be useful in scripts which rotate and age log
125 files. Naturally, this is not relevant if Cron was built to use sys‐
126 log(3).
127
129 In this version of Cron it is possible to use a network-mounted shared
130 /var/spool/cron across a cluster of hosts and specify that only one of
131 the hosts should run the crontab jobs in this directory at any one
132 time. This is done by starting Cron with the -c option, and have the
133 /var/spool/cron/.cron.hostname file contain just one line, which repre‐
134 sents the hostname of whichever host in the cluster should run the
135 jobs. If this file does not exist, or the hostname in it does not
136 match that returned by gethostname(2), then all crontab files in this
137 directory are ignored. This has no effect on cron jobs specified in
138 the /etc/crontab file or on files in the /etc/cron.d directory. These
139 files are always run and considered host-specific.
140 Rather than editing /var/spool/cron/.cron.hostname directly, use the -n
142 option of crontab(1) to specify the host.
143 You should ensure that all hosts in a cluster, and the file server from
145 which they mount the shared crontab directory, have closely synchro‐
146 nised clocks, e.g., using ntpd(8), otherwise the results will be very
147 unpredictable.
148 Using cluster sharing automatically disables inotify support, because
150 inotify cannot be relied on with network-mounted shared file systems.
151
153 All crontab files have to be regular files or symlinks to regular
154 files, they must not be executable or writable for anyone else but the
155 owner. This requirement can be overridden by using the -p option on
156 the crond command line. If inotify support is in use, changes in the
157 symlinked crontabs are not automatically noticed by the cron daemon.
158 The cron daemon must receive a SIGHUP signal to reload the crontabs.
159 This is a limitation of the inotify API.
160 The syslog output will be used instead of mail, when sendmail is not
162 installed.
163
165 crontab(1), crontab(5), inotify(7), pam(8)
166
168 Paul Vixie ⟨vixie@isc.org⟩
169 Marcela Mašláňová ⟨mmaslano@redhat.com⟩
170 Colin Dean ⟨colin@colin-dean.org⟩
171 Tomáš Mráz ⟨tmraz@fedoraproject.org⟩
172cronie 2013-09-26 CRON(8)