Relying on cron to execute periodic processes assumes the system is up continuously. If the system is down when the time comes for a process to be executed, it will be missed. 

anacron is a program (not a daemon) that is run by the anacron subsystem when the system changes runlevel. It is available on linux. It checks that certain jobs have been run within a configured number of days. Its purpose is to ensure that cron jobs are not missed. This requires a handshake to occur between cron and anacron:

• each job whose execution is ensured by the system is given a name
• when the job is run by cron, the job must tell anacron it has been run, by invoking anacron like this:

• when the system comes up, anacron checks that the job it is configured to check has been run within a configured number of days. If it has not been run, anacron waits a configured delay (in minutes) then it runs the job and updates the date it was run.

Note that the granularity of anacron is in days. It is thus not useful for jobs that must be run hourly, and only of limited use for jobs that are run daily.

anacron is not configurable by users, thus it is only useful for checking that root's cron jobs are run.

anacron uses a configuration file, /etc/anacrontab, to tell it what to do. It also keeps a set of timestamps for the jobs it is watching in the directory /var/spool/anacron. The format of the anacrontab is

period delay identifier command

• period - the frequency of execution of the job in days
• delay - number of minutes anacron should wait before running the job (if necessary). 
• identifier - the unique job name
• command - the command used to run the job. This should be the same command used by cron(1).

When anacron starts, it checks the timestamp for the job to see if the job has been run in the last period days. If not, it locks the job (so another instance of anacron won't run it), and waits delay minutes before running it. According to the documentation, only the date is used for this calculation, not the hour. It is unclear how precise this is and how good anacron is at ensuring that jobs whose last execution is at the border of period get run once and only once.

On previous systems, this dual mandate for running jobs could result in a very strange situation where both cron and anacron ran jobs that were configured to be run periodically. As far as I can figure, this would only happen if anacron ran the job first, then cron did. This is very strange, since anacron delays running its job until some minutes after the system is started (the delay) and checks to see if the job has been run. This conflict has evidently been resolved in later releases by having cron read the /etc/anacrontab and dissect anacron's jobs, running them if needed before anacron's delay expires. It is not clear at the time of this writing what the limitations of the new cooperation are, but it means that standard jobs normally configured to be run once at the beginning of each day, week, or month are now only configured only in  /etc/anacrontab. These jobs are run by the run-parts command, which is discussed in the next section.

Example

To understand this better, let's go through the steps necessary to place a job under the control of cron and anacron. Our job has these characteristics

• it must be run on Wednesdays early in the morning
• running it uses a shell script, kept in /etc/weeklyjob.bash. 
• the job will be identified by the job name weeklyjob
• when weeklyjob runs, one of the commands it executes is anacron -u weeklyjob. This tells anacron to update the timestamp for weeklyjob
• one of the lines in /etc/anacrontab is 

• one file in /etc/cron.d contains the line

Scenario 1:

The system is up continuously. cron simply runs the job as scheduled. anacron never runs. 

Scenario 2:

The system goes down Tuesday for several hours. When it comes back up, anacron runs. It compares the current date to the last time weeklyjob was run (last Wednesday) and discovers it was less than 7 days ago. It does not run the job. At ten minutes past midnight on Wednesday morning, cron runs the job.

Scenario 3:

The system goes down Tuesday evening and does not come up until 2am Wednesday morning. When it comes up, anacron runs. It discovers that 7 days have passed since the job was last run, so it runs the job. cron has missed its time to run the job, so the job does not get run again until the following Wednesday. When cron missed the Wednesday morning run, it was run by anacron. (Note: with the new cron behavior of reading the anacrontab, cron may run the job before anacron gets to it.)

Anacron timestamp files

These empty datestamp files are kept in /var/spool/anacron

Summary

anacron can be used to ensure that important cron jobs run with a granularity of at least days are not missed due to the system being down when the job should be run. Ensuring this requires a handshake between anacron and cron that consists of naming the job, placing it under the control of anacron, and having cron update anacron's timestamp file. Although anacron does provide insurance against missing a job, it is unclear at the time of this writing whether the mechanism avoids duplication of jobs under unusual circumstances.

Copyright 2011 Greg Boyd - All Rights Reserved.