This article needs additional citations for
The software utility cron is a time-based
cron is most suitable for scheduling repetitive tasks. Scheduling one-time tasks is often more easily accomplished using the associated
Cron is driven by a crontab (cron table) file, a configuration file that specifies
/etc or a subdirectory of
/etc) that only system administrators can edit.
Each line of a crontab file represents a job, and looks like this:
# ┌───────────── minute (0 - 59) # │ ┌───────────── hour (0 - 23) # │ │ ┌───────────── day of month (1 - 31) # │ │ │ ┌───────────── month (1 - 12) # │ │ │ │ ┌───────────── day of week (0 - 6) (Sunday to Saturday; # │ │ │ │ │ 7 is also Sunday on some systems) # │ │ │ │ │ # │ │ │ │ │ # * * * * * command to execute
The syntax of each line expects a cron expression made of five fields, followed by a shell command to execute.
While normally the job is executed when the time/date specification fields all match the current time and date, there is one exception: if both "day of month" (field 3) and "day of week" (field 5) are restricted (not "*"), then one or both must match the current day.
For example, the following clears the Apache error log at one minute past midnight (00:01) every day, assuming that the default shell for the cron user is
1 0 * * * printf "" > /var/log/apache/error_log
This example runs a shell program called export_dump.sh at 23:45 (11:45 PM) every Saturday.
45 23 * * 6 /home/oracle/scripts/export_dump.sh
The configuration file for a user can be edited by calling
crontab -e regardless of where the actual implementation stores this file.
cron implementations, such as the popular
Some cron implementations support the following non-standard macros:
||Run once a year at midnight of 1 January||
||Run once a month at midnight of the first day of the month||
||Run once a week at midnight on Sunday morning||
||Run once a day at midnight||
||Run once an hour at the beginning of the hour||
||Run at startup||N/A|
@reboot configures a job to run once when the daemon is started. Since cron is typically never restarted, this typically corresponds to the machine being booted. This behavior is enforced in some variations of cron, such as that provided in
@reboot can be useful if there is a need to start up a server or daemon under a particular user, and the user does not have access to configure
These two files play an important role:
Note that if neither of these files exist then, depending on site-dependent configuration parameters, either only the super user can use cron jobs, or all users can use cron jobs.
Most cron implementations simply interpret crontab entries in the system time zone setting that the cron daemon runs under. This can be a source of dispute if a large multi-user machine has users in several time zones, especially if the system default timezone includes the potentially confusing