GNU/Linux provides a high degree of scripting and automation. Cron-like utilities have moved it up to the next level. They provide a cleaner way of executing tasks or jobs in an automated and repeated manner. So if Cron is such a great utility, what is the need for another utility like Anacron?
Cron is ideal for servers, i.e., it expects the system to run 24×7. If, for instance, you had configured a Cron job for 11:30 p.m. and, unfortunately, your system was not up at that time, your Cron job wouldn’t run. If such occurrences take place often, many problems could arise like missing important software updates, regular maintenance activities, regular rotation of log files and so on. The final outcome would be that the system might not be up-to-date or might be in an inconsistent state. Wouldnt it be great if the system remembers when certain scheduled tasks have not been executed and does the needful when it comes up again? Well, Anacron does exactly that.
Anacron is also a task scheduling utility and it executes jobs periodically, with the frequency specified in days only. Since it does not expect the system to run 24 hours a day, it is ideal for laptops or desktops. Anacron ensures that a job that has not been executed due to the system being down, will be executed when the system comes up again. Please note that Anacron is a supplement to Cron and not its complete replacement.
Anacron does not run continuously like a daemon. It is started at system boot up and exits when there are no more jobs to run. Upon start-up, Anacron reads the list of configured jobs from the Anacron table. For each job, it checks whether the current job has been executed in the last n’ days. If not, Anacron waits for the number of minutes specified as the delay parameter in the Anacron table, and starts executing the job. After this is done, it records the job execution date in a special timestamps file. At the next system boot up cycle, this timestamps file is checked to decide whether there is a need for a particular job to be executed or not. Anacron makes sure that only one instance of a job runs at a time by using a locking mechanism. After executing all jobs, Anacron exits.
Understanding the Anacron table
Now that we have understood the need for Anacron and its lifecycle, let us explore the format of the Anacron table. In the Anacron table, each field is separated by a space or a tab character. Shown below is the format of the Anacron table:
{period} {delay} {job-identifier} {command(s)}
OR
{@period_name} {delay} {job-identifier} {command(s)}
Table 1 describes each field of the Anacron table.
Anacron provides a special string value that can be used in place of the period field. The currently supported value for this field is @monthly. This ensures that jobs will be executed once a month, regardless of the number of days in the current or previous month.
Anacron also allows the assignment of values to environment variables in the Anacron table. Please note that Anacron tables are parsed from top to bottom; hence, any environment settings are applicable only to those commands that are specified after setting environment variables. By default SHELL’ is set to /bin/sh. HOME’ is the home directory of the user. LOGNAME’ is the name of the user executing the Anacron job. The default value of PATH’ is /usr/bin:/bin.
By default, after successful command execution, the output is mailed to the owner of the Anacron table (usually the root user). This default behavior can be overridden by setting up a MAILTO’ environment variable. If MAILTO’ is set up and is not empty, then the output of the command is mailed to the user so named. In MAILTO’, multiple recipients can be specified by a comma separated list. If the empty value is assigned to MAILTO’ (e.g., MAILTO=”” ), then no mail is sent.
In the Anacron table, we can assign values to environment variables in the same manner as shell assignment. The simple example given below will give you a clearer idea about the usage of environment variables.
[root]# cat /etc/anacrontab # Set environment variables. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root LOGNAME=root MAILTO="jerry@acme.com" # 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
Additionally, Anacron provides two more variables (given below) that control the scheduled time of the configured jobs.
1) RANDOM_DELAY: This is the maximum number of minutes that will be added to the delay field of each job. The minimum possible value for this variable is 6 minutes.
Here is an example. Let us suppose the value of RANDOM_DELAY is 20 minutes and the value in the delay field is 10 minutes. Then, before job execution, Anacron will wait for 10 minutes (from the delay field) + a random number of minutes between 6-20 (because of RANDOM_DELAY).
2) START_HOURS_RANGE: Anacron overcomes one of the major drawbacks of Cron. If an Anacron job is scheduled for a particular time interval and the system is not running at that time, Anacron guarantees that the job will be executed when the system comes up. But here is a catch. What if the system does not go offline? When should the job be executed? The solution is to specify this range by defining the START_HOURS_RANGE variable.
For example, if the value of START_HOURS_RANGE is 12-18′, then Anacron jobs can be run between 12 a.m. and 6 p.m.
If START_HOURS_RANGE is defined and that time interval is missed, for example, because of a power outage, then the job will not run for that particular day.
Playing with Anacron tables
The two files below play an important role in the Anacron lifecycle.
- /etc/anacrontab: This is a configuration file, which stores the Anacron table and describes the jobs controlled by it.
- /var/spool/anacron: This is the default spool area used by Anacron to store timestamps files.
Anacron stores its table in the /etc/anacrontab file. To create or edit an Anacron table, edit the /etc/anacrontab file directly using your favourite text editor. Please note that the user must be privileged to edit the Anacron table. An Anacron table file might look like the example listing below:
[root]# cat /etc/anacrontab # Set environment variables. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 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
Additionally, we can instruct Anacron to use a specified Anacron table rather than the default one. Anacron’s -t’ option will do the needful. Let us check it out with an example.
Jerry has written his Anacron table in the jerry.anacrontab file and it has the following contents:
[jerry]$ cat /home/jerry/jerry.anacrontab # Set environment variables. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin LOGNAME="jerry" HOME="/home/jerry" MAILTO="jerry@acme.com" 1 5 jerrcron.daily /home/jerry/daily_maintenance.sh 7 10 jerrycron.weekly /home/jerry/weekly_maintenance.sh
To use the above file as an Anacron table instead of the default one, execute the following command:
[jerry]$ anacrontab -t /home/jerry/jerry.anacrontab
This method is useful for a non-root user to run Anacron.To execute a job successfully, Anacron needs its table in a particular format. It is good practice to check the Anacron table for syntax errors. One of the lengthy ways to test it is to copy the Anacron table to the test machine and verify it by executing jobs. It’s better to identify those syntax errors by static analysis, i.e., without running an actual job. Anacron provides the -T’ option. Using it, we can validate the Anacron tables. It validates the syntax of the Anacron table and if errors are found, it reports them on the standard error stream and sets the command exit status to 1. Let us check this out with an example.
We know that Anacron does not support the @hourly’ string. Let us deliberately insert it into the Anacron table. Given below is an example of an Anacron table with a syntax error:
[jerry]$ cat /home/jerry/jerry.anacrontab # Set environment variables. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin LOGNAME="jerry" HOME="/home/jerry" MAILTO="jerry@acme.com" 1 5 jerrcron.daily /home/jerry/daily_maintenance.sh 7 10 jerrycron.weekly /home/jerry/weekly_maintenance.sh @hourly 10 jerrycron.hourly /home/jerry/check_disk_space.sh # Here is error.
Now, validate the Anacron table for syntax errors.
[jerry]$ anacron -t /home/jerry/jerry.anacrontab -T Anacron: /home/jerry/jerry.anacrontab: Unknown named period on line 10, skipping
Also verify the exit status of command.
[jerry]$ echo $? 1
Running Anacron
We have completed our discussion on Anacron tables. Let us now look at different ways of running Anacron.
Running Anacron at system start-up: If your systems start-up and shut-down cycles are very frequent, then launching Anacron at the time of system boot-up is a good choice. Upon system start-up, Anacron can check the list of configured jobs and execute them, if necessary.
For the Ubuntu GNU/Linux distribution /etc/init/Anacron.conf is Anacron’s start-up script which runs all the jobs from /etc/anacrontab. The contents of the /etc/init/Anacron.conf file might vary from version to version. If you are running any other GNU/Linux distribution, then go through your distributions documentation to find out or write the Anacron start-up script.
Running Anacron via Cron: Another popular way to launch Anacron is to run it via Cron. If your computer shuts down or starts up less frequently, then this is a good choice. To launch Anacron via Cron, create a Cron table entry in the /etc/crontab file:
@hourly * * * * root anacron
For the job above, Cron executes Anacron once every hour, and Anacron executes jobs only if necessary.
Running Anacron via a non-root user: In our earlier discussion, we have seen how the root user can run Anacron. But it is a very common requirement to execute Anacron via an ordinary or non-root user. We can achieve this by simply creating a private Anacron table and by specifying a different spool area. To run Anacron via an ordinary user add the following entry into the user’s Cron table or execute Anacron via login scripts:
crontab -t /home/jerry/jerry.anacrontab -S /home/jerry/crontab_spool
where the -t’ option is used to specify a private Anacron table and the -S‘ option is used to specify the spool area that stores the timestamps file.
Insights about Crontab
Anacron is sensitive to signals. The signal SIGUSR1′ can be used to stop Anacron gracefully. After receiving the SIGUSR1′ signal, if there are any running jobs, Anacron waits to finish them and exits gracefully. To know more about signals, refer to the manual page of the kill’ command from your distribution.
By default, Anacron forks out and creates child processes. The parent process exits immediately and child processes start their execution in the background. By providing the -d’ option, we can instruct Anacron not to fork out in the background. In this mode, Anacron will print all messages to the standard error stream as well as send them to the syslog’ daemon. Additionally, it will also e-mail the output according to the MAILTO setting.
Before job execution, Anacron does some pre-checks. Reading the timestamps file is one of them. Anacron then decides whether job execution is needed or not. We can override this default behaviour by using the -f’ option, which forces Anacron to execute the job by ignoring timestamps.
We can also perform dry runs of jobs for testing purposes. The -u’ option of Anacron just updates the timestamps to the current date, but in reality does not run any job.
We can instruct Anacron to start job execution in serial order. The -s’ option of Anacron takes care of that. In serial job execution, the next job will be started only when the previous job completes its execution.
Anacron uses the /var/spool/anacron directory as a spool area to store the timestamps file. We can also use other directories as the spool area by specifying an argument to the -S’ option. This is needed when a non-root user wants to execute a job through Anacron.
Caveats
Although Anacron is a great utility and works intelligently by taking care of missed jobs, it also has some shortcomings. Let us discuss a few of them.
- For Anacron, the smallest possible granularity is days. It does not deal with hours or minutes.
- Anacron creates the timestamps file per job in the spool area, and those files never get removed automatically. If the user removes a particular job entry from an Anacron table, then he has to remove the timestamps file manually.
- For each job execution, Anacron uses up to two file descriptors; so we can easily run out of descriptors if we run a large number of jobs. Please note that this limit varies from one version of GNU/Linux to another.
We have seen that, by combining Anacron with other utilities, we can manage a GNU/Linux system more efficiently. These simple but powerful command-line utilities make GNU/Linux more interesting and reliable.
