cron [-o logfile] [-x debugflags] crontabfile
The cron(1) daemon searches its spool directory (/var/spool/cron/tabs/) for crontab(5) files which are named after fully qualified user names in the form domain+user and loads the crontab files it finds into memory. The cron(1) daemon also searches for /etc/crontab which is in a different format (see crontab(5)). The cron(1) daemon then wakes up every minute, examining all loaded crontab files and checking each command to see if it should be run in the current minute. When executing commands, any output is mailed to the user named in the MAILTO environment variable in the crontab, or to the owner of the crontab if MAILTO is not present. For cron to successfully execute another user's cron jobs, the user must have registered the user's password using crontab -p. Without this password, cron cannot impersonate that user and will not execute the user's crontab commands.
Additionally, cron(1) checks each minute to see if its spool directory's modtime (or the modtime on /etc/crontab) has changed, and if it has, cron(1) examines the modtime on all crontab files and reloads those which have changed. Thus cron(1) need not be restarted whenever a crontab file is modified. Note that the crontab(1) command updates the modtime of the spool directory whenever it changes a crontab file.
Special considerations exist when the clock is changed by less than 3 hours; for example, at the beginning and end of Daylight Saving Time. If the time has moved forward, those jobs which would have run in the time that was skipped will be run soon after the change. Conversely, if the time has moved backward by less than 3 hours, those jobs that fall into the repeated time will not be run.
Only jobs that run at a particular time (not specified as @hourly, nor with * in the hour or minute specifier) are affected. Jobs which are specified with wildcards are run based on the new time immediately.
Clock changes of more than 3 hours are considered to be corrections to the clock, and the new time is used immediately.
In addition to jobs specified in crontab files, cron(1) also looks for at(1) and batch(1) jobs that are queued in /var/spool/cron/atjobs and executes them at the appropriate time.
The crontab file is not required to exist, and can be deleted and recreated without causing cron(1) to exit. A missing crontab file is equivalent to an empty crontab file. The syntax of the crontab file is described in crontab(5).
The cron(1) program writes progress and error messages to stderr. If the -o option is supplied, then the messages are instead written to the specified log file. If the -x option is supplied, then debug messages are also written, as specified by the debugflags argument. The debugflag argument is a comma separated list of keywords, each of which enables a different set of debug messages. The following keywords are recognized:
ext sch proc pars load misc test bit mail
Several environment variables are set up automatically by the cron(1) daemon. INTERIX_ROOT is set to the directory in which Interix is installed. SYSTEMROOT is the path name (in Windows syntax) of the directory in which Windows is installed; it is used by some Win32 programs. TZ is the time zone; it is used by date(1) and a few other Interix utilities. SHELL is set to /bin/sh. PATH is set to /bin:/usr/contrib. LOGNAME and HOME are set from the Windows user database. All of these variables may be overridden by settings in the crontab, except for LOGNAME.
In addition to LOGNAME, HOME, and SHELL, cron(1) will look at MAILTO if it has any reason to send mail as a result of running commands in the crontab. If MAILTO is defined (and non-empty), mail is sent to the user so named. If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Otherwise mail is sent to the owner of the crontab. Mail is sent using mailx(1).
The cron(1) program does not exit unless it is interrupted by a signal.
The progress and log messages that cron(1) writes to stderr are sent to syslogd(1).
By default, Interix does not execute files with the set-user-ID (setuid) or set-group-ID (setgid) mode bit set for security reasons. If an attempt is made to execute such a file, the ENOSETUID error is returned. For more information and and instructions for enabling execution of files with these mode bits set, see The superuser account and appropriate privileges in Windows Services for UNIX Help.
crontab(1)
crontab(5)