CRON(8)

NAME
crond - daemon to execute scheduled commands

SYNOPSIS
crond [-h | -i | -n | -p | -P | -s | -m<mailcommand>]
crond -x [ext,sch,proc,pars,load,misc,test,bit]
crond -V

DESCRIPTION
Cron searches /data/data/com.termux/files/usr/var/spool/cron for crontab file which is being loaded into the memory. Cron also searches for any files in the /data/data/com.termux/files/usr/etc/cron.d directory, which have a different format (see crontab(5)). Cron examines all stored crontabs and checks each job to see if it needs to be run in the current minute. When executing commands, any output is mailed to the owner of the crontab (or to the user specified in the MAILTO environment variable in the crontab, if such exists). Any job output can also be sent to syslog by using the -s option.

There are two ways how changes in crontables are checked. The first method is checking the modtime of a file. The second method is using the inotify support. Using of inotify is logged in the /data/data/com.termux/files/usr/var/log/cron log after the daemon is started. The inotify support checks for changes in all crontables and accesses the hard disk only when a change is detected.

When using the modtime option, Cron checks its crontables' modtimes every minute to check for any changes and reloads the crontables which have changed. There is no need to restart Cron after some of the crontables were modified. The modtime option is also used when inotify can not be initialized.

Cron checks these directories:

/data/data/com.termux/files/usr/etc/cron.d/
    directory that contains system cronjobs stored for different users.

/data/data/com.termux/files/usr/var/spool/cron
    directory that contains user crontables created by the crontab command.

Note that the crontab(1) command updates the modtime of the spool directory whenever it changes a crontab.

  Daylight Saving Time and other time changes
Local time changes of less than three hours, such as those caused by the Daylight Saving Time changes, are handled in a special way. This only applies to jobs that run at a specific time and jobs that run with a granularity greater than one hour. Jobs that run more frequently are scheduled normally.

If time was adjusted one hour forward, those jobs that would have run in the interval that has been skipped will be run immediately. Conversely, if time was adjusted backward, running the same job twice is avoided.

Time changes of more than 3 hours are considered to be corrections to the clock or the timezone, and the new time is used immediately.

It is possible to use different time zones for crontables. See crontab(5) for more information.

OPTIONS

-h  Prints a help message and exits.

-i  Disables inotify support.

-m  This option allows you to specify a shell command to use for sending Cron mail output instead of using sendmail(8) This command must accept a fully formatted mail message (with headers) on standard input and send it as a mail message to the recipients specified in the mail headers. Specifying the string off (i.e., crond -m off) will disable the sending of mail.

-n  Tells the daemon to run in the foreground. This can be useful when starting it out of init.

-f  the same as -n, consistent with other crond implementations.

-p  Allows Cron to accept any user set crontables.

-P  Don't set PATH. PATH is instead inherited from the environment.

-s  This option will direct Cron to send the job output to the system log using syslog(3). This is useful if your system does not have sendmail(8) installed or if mail is disabled.

-x  This option allows you to set debug flags.

-V  Print version and exit.

SIGNALS
When the SIGHUP is received, the Cron daemon will close and reopen its log file. This proves to be useful in scripts which rotate and age log files. Naturally, this is not relevant if Cron was built to use syslog(3).

CAVEATS
All crontab files have to be regular files or symlinks to regular files, they must not be executable or writable for anyone else but the owner. This requirement can be overridden by using the -p option on the crond command line. If inotify support is in use, changes in the symlinked crontabs are not automatically noticed by the cron daemon. The cron daemon must receive a SIGHUP signal to reload the crontabs. This is a limitation of the inotify API.

The syslog output will be used instead of mail, when sendmail is not installed.

SEE ALSO
crontab(1), crontab(5), inotify(7), pam(8)

AUTHOR
Paul Vixie (vixie@isc.org)
Marcela Mašláňová (mmaslano@redhat.com)
Colin Dean (colin@colin-dean.org)
Tomáš Mráz (tmraz@fedoraproject.org)