6.0 KiB
Cron
The cron command is a runner for something that needs to happen on a schedule.
There are different implementations (Dillon's cron, Vixie's cron, chrony, …), and variations of it (e.g., anacron,
systemd timers).
TL;DR
cron searches its spool area (/var/spool/cron/crontabs on Linux systems, /usr/lib/cron/tabs on Mac OS X) for
crontab files named after accounts in /etc/passwd, and loads those it founds into memory.
Note
Crontabs in the spool directory should not be accessed directly.
Thecrontabcommand should be used to access and update them instead.
cron also reads /etc/crontab, which uses a slightly different format (must provide the username to run the task as
in the task definition).
Refer crontab's manual page.
On Linux, support for /etc/cron.d is included in the cron daemon itself, which handles this location as the
system-wide crontab spool.
This directory can contain any file defining tasks following the format used in /etc/crontab).
Debian uses a default configuration for the cron system that is specific to the distribution.
Debian uses /etc/crontab to run crontabs under /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and
/etc/cron.monthly.
Additionally, cron reads files in /etc/cron.d.
Those are treated in the same way as /etc/crontab, and are expected to follow the special format of that file.
However, they are independent from /etc/crontab and they do not inherit environment variable settings from
it.
/etc/crontab and the files in /etc/cron.d must:
- Be owned by the
rootuser. - Not be group- or other-writable.
Files in the above directories are monitored for changes the same way /etc/crontab is.
In contrast to the spool area, those files can also be symlinks, as long as both the symlink and the file it
points to are owned by the root user.
Files under /etc/cron.d do not need to be executable, but files under /etc/cron.{hourly,daily,weekly,monthly}
do, as they are run by run-parts. Refer run-parts' manual page.
Files have to pass some sanity checks, including:
- Be executable.
- Be owned by the
rootuser. - Not be writable by group or other.
- Be named conforming to the filename requirements of
run-parts(must match^[a-zA-Z0-9\_\-]$).
Any file which name does not conform to these requirements will not be executed byrun-parts.
The cron system wakes up every minute, examines all stored crontabs, and checks each command to see if it should be
executed in the current minute.
When executing commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO
environment variable in the crontab, if such exists) from the owner of the crontab (or from the email address
given in the MAILFROM environment variable in the crontab, if such exists).
Note
Children copies of
cronrunning processes have their name coerced to uppercase.
Those will be visible in the output of thesyslogandpscommands.
Additionally, cron checks every minute if its spool directory's modtime (or the modtime for the /etc/crontab file)
has changed. In this case, cron examines the modtime on all crontabs and reloads those which have changed.
This prevents cron from needing to be restarted whenever a crontab file is modified.
Note
The
crontabcommand updates the modtime of the spool directory whenever it changes any crontab in it.
Clock changes of more than 3 hours are considered to be corrections to the clock, and the new time is used
immediately.
When the system clock is changed by less than 3 hours (e.g., at the beginning and end of daylight savings time), jobs
will be executed accordingly:
- If the time moved forwards, jobs which would have run in the time that was skipped will be run soon after the time change.
- if the time moved backwards by less than 3 hours, jobs that fall into the repeated time will not be run again.
Only jobs running at a particular time (not specified as @hourly, nor with * in the hour or minute specifier) are
affected by time changes.
Jobs specified with wildcards are run based on the new time immediately.
cron logs its action to the cron syslog facility. Logging can be checked using the standard syslogd facility.
Modern cron implementations have added the @hourly, @daily, @weekly, @monthly, and @yearly or @annually
shorthands for common schedules.
apt install 'cron'
systemctl --enable --now 'crond.service'
journalctl -xefu 'crond.service'
# Validate crontab files.
crontab -T '/etc/cron.d/prometheus-backup'
# List files in given directories.
# Kinda… useless?
run-parts --list '/etc/cron.daily'
# Print the names of the scripts which would be invoked.
# '--report' is *not* available everywhere.
run-parts --report --test '/etc/cron.hourly'
# Manually run crontab files in given directories.
run-parts '/etc/cron.weekly'
# Check scripts run.
grep 'CRON' '/var/log/syslog'