-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathcrond.8.html
234 lines (234 loc) · 11.6 KB
/
crond.8.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<link rel="stylesheet" href="mandoc.css" type="text/css" media="all"/>
<title>CROND(8)</title>
</head>
<body>
<table class="head">
<tr>
<td class="head-ltitle">CROND(8)</td>
<td class="head-vol">System Manager's Manual</td>
<td class="head-rtitle">CROND(8)</td>
</tr>
</table>
<div class="manual-text">
<section class="Sh">
<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1>
<p class="Pp">crond - dillon's lightweight cron daemon</p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp"><b>crond [-s dir] [-c dir] [-t dir] [-m user@host] [-M
mailhandler] [-S|-L file] [-P|-p file] [-l loglevel] [-b|-f|-d]</b></p>
</section>
<section class="Sh">
<h1 class="Sh" id="OPTIONS"><a class="permalink" href="#OPTIONS">OPTIONS</a></h1>
<p class="Pp"><b>crond</b> is a background daemon that parses individual crontab
files and executes commands on behalf of the users in question.</p>
<dl class="Bl-tag">
<dt id="s"><a class="permalink" href="#s"><b>-s dir</b></a></dt>
<dd>directory of system crontabs (defaults to /etc/cron.d)</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="c"><a class="permalink" href="#c"><b>-c dir</b></a></dt>
<dd>directory of per-user crontabs (defaults to /var/spool/cron/crontabs)</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="t"><a class="permalink" href="#t"><b>-t dir</b></a></dt>
<dd>directory of timestamps for @freq and FREQ=... jobs (defaults to
/var/spool/cron/cronstamps)</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="m"><a class="permalink" href="#m"><b>-m user@host</b></a></dt>
<dd>where should the output of cronjobs be directed? (defaults to local user)
Some mail handlers (like msmtp) can't route mail to local users. If that's
what you're using, then you should supply a remote address using this
switch. Cron output for all users will be directed to that address.
Alternatively, you could supply a different mail handler using the -M
switch, to log or otherwise process the messages instead of mailing them.
Alternatively, you could just direct the stdout and stderr of your cron
jobs to /dev/null.</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="M"><a class="permalink" href="#M"><b>-M mailhandler</b></a></dt>
<dd>Any output that cronjobs print to stdout or stderr gets formatted as an
email and piped to
/usr/sbin/sendmail -t -oem -i<b>.</b> <b>Attempts to
mail this are also logged.</b> <b>This switch permits the user to
substitute a different mailhandler,</b> <b>or a script, for sendmail.</b>
<b>That custom mailhandler is called with no arguments, and with the</b>
<b>mail headers and cronjob output supplied to stdin.</b> <b>When a custom
mailhandler is used, mailing is no longer logged</b> <b>(have your
mailhandler do that if you want it).</b> <b>When cron jobs generate no
stdout or stderr, nothing is sent to</b> <b>either sendmail or a custom
mailhandler.</b></dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="S"><a class="permalink" href="#S"><b>-S</b></a></dt>
<dd>log events to syslog, using syslog facility LOG_CRON and identity `crond'
(this is the default behavior).</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="L"><a class="permalink" href="#L"><b>-L file</b></a></dt>
<dd>log to specified file instead of syslog.</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="P"><a class="permalink" href="#P"><b>-P</b></a></dt>
<dd>do not create a process-id file.</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="L~2"><a class="permalink" href="#L~2"><b>-L file</b></a></dt>
<dd>Write process-id to specified file instead of /var/run/crond.pi</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="l"><a class="permalink" href="#l"><b>-l loglevel</b></a></dt>
<dd>log events at the specified, or more important, loglevels. The default is
`notice'. Valid level names are as described in logger(1) and syslog(3):
alert, crit, debug, emerg, err, error (deprecated synonym for err), info,
notice, panic (deprecated synonym for emerg), warning, warn (deprecated
synonym for warning).</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="b"><a class="permalink" href="#b"><b>-b</b></a></dt>
<dd>run <b>crond</b> in the background (default unless -d or -f is
specified)</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="f"><a class="permalink" href="#f"><b>-f</b></a></dt>
<dd>run <b>crond</b> in the foreground. All log messages are sent to stderr
instead of syslog or a -L file.</dd>
</dl>
<div class="Bd-indent"></div>
<dl class="Bl-tag">
<dt id="d"><a class="permalink" href="#d"><b>-d</b></a></dt>
<dd>turn on debugging. This option sets the logging level to `debug' and
causes <b>crond</b> to run in the foreground.</dd>
</dl>
<div class="Bd-indent"></div>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp"><b>crond</b> is responsible for scanning the crontab files and
running their commands at the appropriate time. It always synchronizes to
the top of the minute, matching the current time against its internal list
of parsed crontabs. That list is stored so that it can be scanned very
quickly, and <b>crond</b> can deal with several hundred crontabs with
several thousand entries without using noticeable CPU.</p>
<p class="Pp">Cron jobs are not re-executed if a previous instance of them is
still running. For example, if you have a crontab command
sleep 70<b>, that</b> <b>you request to be run every minute,
</b><b>crond</b><b> will skip this</b> <b>job when it sees it is still
running.</b> <b>So the job won't be run more frequently than once every
two</b> <b>minutes.</b> <b>If you do not like this feature, you can run your
commands in the</b> <b>background with an &</b><b>.</b></p>
<p class="Pp"><b>crond</b> automatically detects when the clock has been
changed, during its per-minute scans. Backwards time-changes of an hour or
less won't re-run cron jobs from the intervening period. <b>crond</b> will
effectively sleep until it catches back up to the original time. Forwards
time-changes of an hour or less (or if the computer is suspended and resumed
again within an hour) will run any missed jobs exactly once. Changes greater
than an hour in either direction cause <b>crond</b> to re-calculate when
jobs should be run, and not attempt to execute any missed commands. This is
effectively the same as if <b>crond</b> had been stopped and re-started.</p>
<p class="Pp">For example, suppose it's 10 am, and a job is scheduled to run
every day at 10:30 am. If you set the system's clock forward to 11 am, crond
will immediately run the 10:30 job. If on the other hand you set the
system's clock forward to noon, the 10:30 am job will be skipped until the
next day. Jobs scheduled using @daily and the like work differently; see
crontab(1) for details.</p>
<p class="Pp"><b>crond</b> has a number of built in limitations to reduce the
chance of it being ill-used. Potentially infinite loops during parsing are
dealt with via a failsafe counter, and non-root crontabs are limited to 256
crontab entries. Crontab lines may not be longer than 1024 characters,
including the newline.</p>
<p class="Pp">Whenever <b>crond</b> must run a job, it first creates a
daemon-owned temporary file O_EXCL and O_APPEND to store any output, then
fork()s and changes its user and group permissions to match that of the user
the job is being run for, then <b>exec</b>s <b>/bin/sh -c </b> to run the
job. The temporary file remains under the ownership of the daemon to prevent
the user from tampering with it. Upon job completion, <b>crond</b> verifies
the secureness of the mail file and, if it has been appended to, mails the
file to the specified address. The <b>sendmail</b> program (or custom mail
handler, if supplied) is run under the user's uid to prevent mail related
security holes.</p>
<p class="Pp">When a user edits their crontab, <b>crontab</b> first copies the
crontab to a user owned file before running the user's preferred editor. The
suid <b>crontab</b> keeps an open descriptor to the file which it later uses
to copy the file back, thereby ensuring the user has not tampered with the
file type.</p>
<p class="Pp"><b>crontab</b> notifies <b>crond</b> that a user's crontab file
has been modified (or created or deleted) through the
“cron.update” file, which resides in the per-user crontabs
directory (usually /var/spool/cron/crontabs). <b>crontab</b> appends the
filename of the modified crontab file to “cron.update”; and
<b>crond</b> inspects this file to determine when to reparse or otherwise
update its internal list of parsed crontabs.</p>
<p class="Pp">Whenever a “cron.update” file is seen, <b>crond</b>
also re-reads timestamp files from its timestamp directory (usually
/var/spool/cron/cronstamps). Normally these will just mirror <b>crond</b>'s
own internal representations, but this mechanism could be used to manually
notify <b>crond</b> that you've externally updated the timestamps.</p>
<p class="Pp">The “cron.update” file can also be used to ask
<b>crond</b> to schedule a “named” cron job. To do this,
append a line of the form:</p>
<dl class="Bl-tag">
<dt></dt>
<dd>
<pre>
clio job1 !job2
<b></b></pre>
</dd>
</dl>
<p class="Pp">to “cron.update”. This request that user clio's job1
should be scheduled (waiting first for the successful completion of any jobs
named in job1's AFTER= tag), and job2 should also be scheduled (without
waiting for other jobs). See crontab(1) for more about tags and named
jobs.</p>
<p class="Pp">The directory of per-user crontabs is re-parsed once every hour in
any case. Any crontabs in the system directory (usually /etc/cron.d) are
parsed at the same time. This directory can be used by packaging systems.
When you install a package foo, it might write its own foo-specific crontab
to /etc/cron.d/foo.</p>
<p class="Pp">The superuser has a per-user crontab along with other users. It
usually resides at /var/spool/cron/crontabs/root.</p>
<p class="Pp">Users can only have a crontab if they have an entry in
/etc/passwd; however they do not need to have login shell privileges. Cron
jobs are always run under /bin/sh; see crontab(1) for more details.</p>
<p class="Pp">Unlike <b>crontab</b>, the <b>crond</b> program does not keep open
descriptors to crontab files while running their jobs, as this could cause
<b>crond</b> to run out of descriptors.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
ALSO</a></h1>
<p class="Pp"><b>crontab</b>(1)</p>
</section>
<section class="Sh">
<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1>
<p class="Pp">Matthew Dillon ([email protected]): original
developer</p>
<p class="Pp">Jim Pryor ([email protected]): current developer</p>
</section>
</div>
<table class="foot">
<tr>
<td class="foot-date">1 May 2011</td>
<td class="foot-os"></td>
</tr>
</table>
</body>
</html>