You can execute tasks (such as backups, database updates, rotating logs, etc.) periodically using cron and crontab facilities. The cron system is managed by the cron daemon. Daemon processes run continuously once initialized at system startup. Cron runs in the background and tasks scheduled with cron, referred to as cron jobs, are executed automatically. Cron jobs are recorded and managed in a special configuration file known as a crontab.
Installing Cron
If you do not have cron on your system (check with the command: which cron), install it using APT package manager as below:
sudo apt update(update local index of the available packages).sudo apt install cron(install cron).sudo systemctl enable cron(ensure it’s set to run in the background).
How Cron Works
Cron gets information about which programs and when they should run from the system's and users' crontab entries. On most workstation installations, /var/spool will at least contain a cron directory, containing scheduled tasks. Each user on the system can have their own crontab file where they can schedule jobs, and which is stored in the /var/spool/cron/crontabs/ directory. The /etc/crontab is a system-wide crontab available only to the root user. We focus on user-specific crontabs.
At system startup the cron daemon searches /var/spool/cron/ for crontab entries which are named after accounts in /etc/passwd, it searches /etc/cron.d/ (software/package specific cron jobs) and it searches /etc/crontab, then uses this information every minute to check if there is something to be done. If there is, it executes the commands as the user who owns the crontab file.
Managing Crontabs
Users are supposed to edit their crontabs in a safe way using the crontab -e command. This will prevent a user from accidentally opening more than one copy of their crontab file. It will also allow the user to edit their crontab without administrative privileges. Additionally, it will let you know if you have syntax errors in the crontab - editing it directly will not.
In the crontab, some directives are first set, and after that there's the actual scheduling, one line per job, starting with five time and date fields. The first field contains the minutes (from 0 to 59), the second defines the hour of execution (0-23), the third is day of the month (1-31), then the number of the month (1-12), the last is day of the week (0-7, both 0 and 7 are Sunday). An asterisk (*) in these fields represents the total acceptable range for the field. Lists are allowed; to execute a job from Monday to Friday enter 1-5 in the last field, to execute a job on Monday, Wednesday and Friday enter 1,3,5. In the crontab file, the entries are structured like this:
Minute Hour Day Month Weekday Command
Here’s an example of a cron job definition:
38 16 * * 3 mail -s "sports evening" billy (reminds billy to go to his sports club every Wednesday evening)4 4 * * 4,7 /home/billy/bin/backup.sh (executes backup.sh every Thursday and Sunday)
You can use a forward slash with an asterisk to express a step value. Use integers that divide evenly into the range allowed by the field in question. For example, to run a command every 3 hours, you can use this:0 */3 * * * ...
Use the crontab -l command to display the contents of your crontab, but not edit it. To verify that a crontab file exists for a user, issue the ls -l command in /var/spool/cron/crontabs directory. To view a specific user’s crontabs, run: sudo crontab -u user -l. You can edit another user’s crontab with the following command: sudo crontab -u user -e. You must have superuser privileges to create or edit a crontab file for root or another user. Finally, you can erase your crontab with the following command: crontab -r -i.
Note: In the system-wide crontab, the user who should run the commands is listed in the field after the time and date fields of a crontab entry. You don't have to specify the user who should run the commands in a user-specific crontab. They are executed with the user's own permissions by default.
When you quit (say, :wq using Vim), after adding a new scheduled task, the system will tell you that a new crontab is installed. You do not need to restart the cron daemon for the changes to take effect.
Managing Cron Job Output
Because cron jobs are executed in the background, it isn’t always apparent that they’ve run successfully. You can redirect the output of cron jobs to help you monitor if they have executed successfully. You could mail output of commands to the owner if you specified a MAILTO setting at the top of the crontab file. If no mail service is configured, you might find the output of your commands in your local mailbox, /var/spool/mail/username, a plain text file.
This job will return “Ran command successfully” and that output will get emailed every 3 hours to the email address specified after the MAILTO directive.0 */3 * * * echo ‘Ran command successfully’
You can also redirect a cron task’s output into a log file or into an empty location to prevent getting an email with the output. To append a scheduled command’s output to a log file, add the >> operator at the end of the command followed by the name and location of your log file, like this:0 */3 * * * echo ‘Ran command successfully’ >> /path/to/file.log
You may sometimes want to use cron to run a script but keep it running in the background. To do that redirect the script’s standard output and error to an empty location. For example, the following cron job executes a PHP script and runs it silently in the background:0 */3 * * * /usr/bin/php /var/www/domain.com/backup.php > /dev/null 2>&1
Even if the crontab contains a MAILTO directive, the command’s output won’t be sent to the specified email address.