What is crontab?
Crontab is a Unix command that creates a table or list of commands, each of which is to be executed by the operating system (OS) at a specified time and on a regular schedule. Crontab is used to create the crontab file (the list) and later used to change the previously created crontab file.
Crontab, which is short for cron table, is a file containing the schedule of various cron entries that should be run at specified times. Another way of describing crontab is as a utility that enables tasks to run automatically at regular intervals in the background by the cron daemon (see below).
The crontab file contains simple instructions for the daemon that mean “run this command at this time on this date.” These instructions specify which command will be executed, on which date and at what time. The file location varies depending on the OS.
In Unix and Linux, cron is a daemon, which is an unattended program that runs continuously in the background and wakes up (executes) to handle periodic service requests when required. The daemon runs when the system boots from /etc/init.d or /etc/rc.d/init.d scripts. Thus, it can be started or stopped — or restarted — using the init script or with a command service crond start in Linux systems.
The term cron has its roots in Greek, where cron means time. Crontab is both the set schedule of commands that will be run, as well as the program used to edit that schedule. It can have multiple execution statements, and each user can define their own crontab. So, the commands defined in a crontab will be executed under the user who owns that crontab.
Crontab and cron jobs
A cron job is a command that the cron daemon runs at regularly scheduled intervals. It is also known as a cron schedule since it includes specific instructions about the commands that should be executed and when.
A user can submit a cron job by specifying the crontab command with the -e flag (see crontab commands section below). The command invokes an editing session so the user can create a crontab file and add entries for each cron job in the file. All entries must be in a form that are acceptable to the cron daemon.
By default, the user receives an email when the cron job is executed. If the email is not required, this command should be added at the end of the cron job line:
>/dev/null 2>&1
What are some common crontab commands and fields?
The command export EDITOR=vi specifies an editor to open a crontab file.
Some of the most common crontab commands are the following:
- crontab -e UserName. It enables the user to edit the crontab file or create a new file. When editing is complete, the file gets copied into the crontab directory as that particular user’s crontab file (see below).
- crontab -l UserName. It lists the cron jobs and displays the contents of the user’s crontab file.
- crontab -r UserName. It removes the crontab file from the crontab directory.
- crontab -v UserName. This command is not available on all systems. It displays the last time a user edited their crontab file and lists the status of the user’s cron jobs.
How do you create a crontab file?
One way to create a crontab file is to specify the File parameter. If the file exists, it and all its entries must be in the format expected by and acceptable to the cron daemon. If the file doesn’t exist, the crontab command invokes the editor. It uses the virtual instrument file editor if the EDITOR environment variable doesn’t exist. If it does, the command invokes the specified editor.
Once the user creates entries and exits the file, the crontab command copies the file into the /var/spool/cron/crontabs directory and places it in a file named for the current user. If a file with that user’s name already exists in the crontabs directory, the command overwrites it.
The owner of the crontab file — or the root user — can use the optional UserName parameter to edit, list, remove or verify the status of the cron jobs for that specific user. If the parameter is invalid, an error message is generated, and the program exits. Crontab flags are available for the root and current user if the parameter is not specified.
Crontab file syntax
A crontab file contains entries for each cron job, with each entry separated from the next by newline characters. Also, each entry contains six fields separated by spaces:
- Minute: Range from 0 to 59
- Hour: Range from 0 to 23
- Day of the month: Range from 1 to 31
- Month: Range from 1 to 12
- Day of the week: Range from 0 to 6, where 0 = Sunday
- Command (shell command)
Any nonexistent times, e.g., the missing hours during Daylight Saving Time conversions, will not match, so any jobs scheduled during these times will not run. Also, when times occur more than once, all matching jobs will be run twice.
Here’s how a crontab file entry looks from left to right:
minute hour day_of_month month weekday command
The above value columns in the command can have * (all allowed values) or specific elements separated by commas. Each element can be either a single number or two numbers separated by a hyphen to indicate an inclusive range.
Here are three examples.
Example 1
15 * * * * rm/home/someuser/tmp/*
This line will get the cron command to run every 15 minutes of an hour every day to remove the tmp files from rm/home/someuser/tmp.
Example 2
* 10 * * * rm/home/someuser/tmp/*
This line will get the cron command to run every 10th hour of every day to remove the tmp files from rm/home/someuser/tmp.
Example 3
0 0 1,25 * 1 command
This line will run the command on the first and 25th days of every month, plus every Monday.
What are crontab restrictions?
It’s important for users to keep in mind these crontab restrictions:
- Users can execute crontab if their name appears in the file /usr/lib/cron/cron.allow.
- If the file doesn’t exist, they can use crontab, as long as their name doesn’t appear in the file /usr/lib/cron/cron.deny.
- If the file /usr/lib/cron/cron.deny exists but is empty, all users can use crontab.
- If neither file /usr/lib/cron/cron.deny nor /usr/lib/cron/cron.allow exist, only root users can use crontab.
Simply put, the allow and deny files determine which users — other than the root users — can use the crontab command. In both the files, one username is listed per line.
Also, if a user’s login ID is associated with more than one login name, the crontab command will use the first login name in the /etc/passwd file. In addition, the daemon attribute in the /etc/security/user file should be set to TRUE using the chuser command to enable users to start cron jobs.
How are changes checked in cron tables?
Changes in cron tables can be checked in one of two ways. Under the first method, the modtime of a file is checked. In this case, cron checks the modtimes of its cron tables every minute to identify changes and then reloads the cron tables that have changed. Even if some cron tables are modified, there’s no need to restart cron after the modifications happen. This method can also be used when inotify cannot be initialized (see below).
The second method to check changes in cron tables requires the use of inotify support. When inotify is used, the activity gets logged in the /var/log/cron log after the daemon is started. It checks for changes in all cron tables and accesses the system hard drive only when a change is detected.
Here are all the files and directories that cron will check:
- /etc/crontab. This is the system crontab. Jobs run through anacron by default, which reads the /etc/anacrontab configuration file.
- /etc/cron.d/. This directory contains system cron jobs stored for different users.
- /var/spool/cron. This directory contains user cron tables created by the crontab
Security and audits in crontab
One security feature in crontab is that only the owner of the crontab file or a root user can use UserName following the -e, -l, -r and -v flags (see the common commands section) to edit, list, remove or verify the crontab file of that specified user.
In addition, the cron daemon runs commands according to the entries in the crontab file. If a user incorrectly specifies a cron job in the file, the daemon will not run the job. Also, the daemon mails the user any command output or errors — unless the user redirected the output of a cron job to standard output or error.
The daemon must first be initialized to examine the crontab file. When a user makes changes to their crontab file — using the crontab command — the cron daemon receives a message indicating the change, so there’s no need to keep checking for new or changed files at regularly scheduled intervals, which can add to the user’s overhead.
The crontab command generates an audit record whenever the command is run. For this, the auditing subsystem must be properly configured. It must also be enabled.
The event CRON_JobRemove lists which users removed a crontab file and when, and the event CRON_JobAdd lists which users edited a crontab file and when.
