In this article, we will explain cron and anacron and also shows you how to setup anacron on Linux. We will as well cover a comparison of these two utilities.
To schedule a task on given or later time, you can use the ‘at’ or ‘batch’ commands and to set up commands to run repeatedly, you can employ the cron and anacron facilities.
Cron – is a daemon used to run scheduled tasks such as system backups, updates and many more. It is suitable for running scheduled tasks on machines that will run continuously 24X7 such as servers.
The commands/tasks are scripted into cron jobs which are scheduled in crontab files. The default system crontab file is /etc/crontab, but each user can also create their own crontab file that can launch commands at times that the user defines.
To create a personal crontab file, simply type the following:
$ crontab -e
How to Setup Anacron in Linux
Anacron is used to run commands periodically with a frequency defined in days. It works a little different from cron; assumes that a machine will not be powered on all the time.
It is appropriate for running daily, weekly, and monthly scheduled jobs normally run by cron, on machines that will not run 24-7 such as laptops and desktops machines.
Assuming you have a scheduled task (such as a backup script) to be run using cron every midnight, possibly when your asleep, and your desktop/laptop is off by that time. Your backup script will not be executed.
However, if you use anacron, you can be assured that the next time you power on the desktop/laptop again, the backup script will be executed.
How Anacron Works in Linux
anacron jobs are listed in /etc/anacrontab and jobs can be scheduled using the format below (comments inside anacrontab file must start with #).
period delay job-identifier command
From the above format:
- period – this is the frequency of job execution specified in days or as @daily, @weekly, or @monthly for once per day, week, or month. You can as well use numbers: 1 – daily, 7 – weekly, 30 – monthly and N – number of days.
- delay – it’s the number of minutes to wait before executing a job.
- job-id – it’s the distinctive name for the job written in log files.
To view example files, type:
$ ls -l /var/spool/anacron/ total 12 -rw------- 1 root root 9 Jun 1 10:25 cron.daily -rw------- 1 root root 9 May 27 11:01 cron.monthly -rw------- 1 root root 9 May 30 10:28 cron.weekly
- command – it’s the command or shell script to be executed.
This is what practically happens:
- Anacron will check if a job has been executed within the specified period in the period field. If not, it executes the command specified in the command field after waiting the number of minutes specified in the delay field.
- Once the job has been executed, it records the date in a timestamp file in the /var/spool/anacron directory with the name specified in the job-id (timestamp file name) field.
Let’s now look at an example. This will run the /home/aaronkilik/bin/backup.sh script everyday:
@daily 10 example.daily /bin/bash /home/aaronkilik/bin/backup.sh
If the machine is off when the backup.sh job is expected to run, anacron will run it 10 minutes after the machine is powered on without having to wait for another 7 days.
There are two important variables in the anacrontab file that you should understand:
- START_HOURS_RANGE – this sets time range in which jobs will be started (i.e execute jobs during the following hours only).
- RANDOM_DELAY – this defines the maximum random delay added to the user defined delay of a job (by default it’s 45).
This is how your anacrontab file would possibly look like.
# /etc/anacrontab: configuration file for anacron # See anacron(8) and anacrontab(5) for details. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root LOGNAME=root # These replace cron's entries 1 5 cron.daily run-parts --report /etc/cron.daily 7 10 cron.weekly run-parts --report /etc/cron.weekly @monthly 15 cron.monthly run-parts --report /etc/cron.monthly @daily 10 example.daily /bin/bash /home/aaronkilik/bin/backup.sh
The following is a comparison of cron and anacron to help you understand when to use either of them.
|It’s a daemon||It’s not a daemon|
|Appropriate for server machines||Appropriate for desktop/laptop machines|
|Enables you to run scheduled jobs every minute||Only enables you to run scheduled jobs on daily basis|
|Doesn’t executed a scheduled job when the machine if off||If the machine if off when a scheduled job is due, it will execute a scheduled job when the machine is powered on the next time|
|Can be used by both normal users and root||Can only be used by root unless otherwise (enabled for normal users with specific configs)|
The major difference between cron and anacron is that cron works effectively on machines that will run continuously while anacron is intended for machines that will be powered off in a day or week.
If you know any other way, do share with us using the comment form below.
10 thoughts on “Cron Vs Anacron: How to Schedule Jobs Using Anacron on Linux”
Great article. Clarified a lot. Great examples. Should be in “man anacron“.
@daily and @weekly don’t work on recent ubuntu versions. Use period `1` or `7` instead.
Please fix this in your article, there are questions of questions on stack exchange from people who ran into that, maybe these questions are from people who were confused after reading your article. At least I was.
(also, 30 is *not* the same as `monthly`, that’s the reason that an alias exists for monthly, but not for weekly/daily)
Thanks for the clarification, I will update the article with the recent changes to Ubuntu…
I will never understand:
You are completely right with all of this.
I use Void Linux and I don’t use cron at all (it’s not even installed).
I create a service and schedule it with snooze – which is what cron should be.
Thanks for this, it is really helpful!
Thanks for this, I found it really helpful! One comment though, are you sure @daily works? I thought @monthly was the only kind of string of that type supported by anacron, and when I checked an anacrontab file for syntax using the
-Tflag and an @daily job, it didn’t like this line and just skipped it. Establishing the period of the job with 1 instead of @daily worked.
@daily works, it supports for scheduling daily tasks. If you scheduled a task using @daily and it didn’t work, you might have configured it wrongly. But we will find out more about your concern. Thanks for liking this article.
Just confirming it works for me now too, I had a mistake elsewhere. Thanks!
Okay, that is great! Many thanks for following us.