crond.markdown

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