CROND(8)CROND(8)NAMEcrond - dillon's lightweight cron daemon
SYNOPSIScrond [-s dir] [-c dir] [-t dir] [-m user@host] [-M mailhandler] [-S|-L
file] [-l loglevel] [-b|-f|-d]
OPTIONScrond is a background daemon that parses individual crontab files and
executes commands on behalf of the users in question.
-s dir directory of system crontabs (defaults to /etc/cron.d)
-c dir directory of per-user crontabs (defaults to
/var/spool/cron/crontabs)
-t dir directory of timestamps for @freq and FREQ=... jobs (defaults to
/var/spool/cron/cronstamps)
-m user@host
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 sup‐
ply 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.
-M mailhandler
Any output that cronjobs print to stdout or stderr gets format‐
ted as an email and piped to /usr/sbin/sendmail -t -oem -i.
Attempts to mail this are also logged. This switch permits the
user to substitute a different mailhandler, or a script, for
sendmail. That custom mailhandler is called with no arguments,
and with the mail headers and cronjob output supplied to stdin.
When a custom mailhandler is used, mailing is no longer logged
(have your mailhandler do that if you want it). When cron jobs
generate no stdout or stderr, nothing is sent to either sendmail
or a custom mailhandler.
-S log events to syslog, using syslog facility LOG_CRON and iden‐
tity `crond' (this is the default behavior).
-L file
log to specified file instead of syslog.
-l loglevel
log events at the specified, or more important, loglevels. The
default is `notice'. Valid level names are as described in log‐
ger(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 warn‐
ing).
-b run crond in the background (default unless -d or -f is speci‐
fied)
-f run crond in the foreground. All log messages are sent to
stderr instead of syslog or a -L file.
-d turn on debugging. This option sets the logging level to
`debug' and causes crond to run in the foreground.
DESCRIPTIONcrond 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 crond can deal with several hundred crontabs with several
thousand entries without using noticeable CPU.
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, that you
request to be run every minute, crond will skip this job when it sees
it is still running. So the job won't be run more frequently than once
every two minutes. If you do not like this feature, you can run your
commands in the background with an &.
crond 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. crond 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 crond to re-calculate
when jobs should be run, and not attempt to execute any missed com‐
mands. This is effectively the same as if crond had been stopped and
re-started.
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 differ‐
ently; see crontab(1) for details.
crond 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.
Whenever crond must run a job, it first creates a daemon-owned tempo‐
rary 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 execs /bin/sh -c to run the job. The tem‐
porary file remains under the ownership of the daemon to prevent the
user from tampering with it. Upon job completion, crond verifies the
secureness of the mail file and, if it has been appended to, mails the
file to the specified address. The sendmail program (or custom mail
handler, if supplied) is run under the user's uid to prevent mail
related security holes.
When a user edits their crontab, crontab first copies the crontab to a
user owned file before running the user's preferred editor. The suid
crontab 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.
crontab notifies crond 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).
crontab appends the filename of the modified crontab file to
“cron.update”; and crond inspects this file to determine when to
reparse or otherwise update its internal list of parsed crontabs.
Whenever a “cron.update” file is seen, crond also re-reads timestamp
files from its timestamp directory (usually /var/spool/cron/cron‐
stamps). Normally these will just mirror crond's own internal repre‐
sentations, but this mechanism could be used to manually notify crond
that you've externally updated the timestamps.
The “cron.update” file can also be used to ask crond to schedule a
“named” cron job. To do this, append a line of the form:
clio job1 !job2
to “cron.update”. This request that user clio's job1 should be sched‐
uled (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.
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 sys‐
tems. When you install a package foo, it might write its own foo-spe‐
cific crontab to /etc/cron.d/foo.
The superuser has a per-user crontab along with other users. It usu‐
ally resides at /var/spool/cron/crontabs/root.
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.
Unlike crontab, the crond program does not keep open descriptors to
crontab files while running their jobs, as this could cause crond to
run out of descriptors.
SEE ALSOcrontab(1)AUTHORS
Matthew Dillon (dillon@apollo.backplane.com): original developer
Jim Pryor (profjim@jimpryor.net): current developer
1 May 2011 CROND(8)