The problem

If you run Linux (or most other UNIXes) on a desktop or laptop computer, that system may be powered down from time to time. Indeed, some systems might be turned off for more minutes per day than they're turned on. This practice can help save on power bills and, in the case of laptops, it's a practical necessity when the computer is transported or not plugged into a wall outlet for an extended period. Unfortunately, such periods of computer inactivity cause problems for Linux, which uses a utility called Cron to run routine maintenance tasks in the background. When these jobs don't run, problems can develop, causing degradation to the system's performance over time.

Cron is intended to launch programs in an unattended manner at specified times. Broadly speaking, two types of Cron jobs (that is, programs run by Cron) exist: system Cron jobs, which are run by the system to perform system maintenance tasks, and user Cron jobs, which are created by users to handle user tasks. Of these two types, system Cron jobs are the more important. These jobs may include tasks such as clearing stale files out of /tmp, rotating log files, updating spam-filter rules, and updating the locate database.

Most Linux systems include a series of subdirectories in /etc related to Cron. The /etc/crontab file specifies what jobs Cron should run as system Cron jobs. Typically, this file tells Cron to run the scripts located in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly on an hourly, daily, weekly, and monthly basis, respectively. The precise times that these jobs run are specified in /etc/crontab. For the daily and longer intervals, these times are typically early in the morning. The trouble is that desktop and laptop systems are likely to be powered down at these times.

When Cron jobs fail to run, various problems can occur. The details vary depending on what the Cron jobs should have done, but examples include huge log files, a cluttered /tmp directory, and out-of-date databases for available software updates or the locations of local system commands.

Clearly, keeping Cron jobs running is important. If a system is to be shut down on a regular basis, you should find a way to avoid these problems. Anacron is just such a solution.

Back to top

Getting started with Anacron

If you administer a system that could benefit from Anacron, you should begin by learning what it does. You can then obtain and install the software, configure it, and link it to your existing Cron configuration.

Basic principles of Anacron

Anacron is not intended as a complete Cron replacement. Although Cron has serious problems on a system that is shut down regularly, it is still the tool of choice for jobs that run frequently, such as hourly checks for new e-mail on a remote mail server. Anacron is designed to supplement, rather than replace, Cron.

Unlike Cron, which runs as a daemon, Anacron runs as an ordinary process and then terminates. Anacron maintains a list of jobs it should run, each of which has an associated run interval. Each time it runs, Anacron checks its job list to see if it's been longer than the specified interval since a job was last run. If so, Anacron runs that job.

This design means that Anacron must be run at regular intervals. The Running Anacron section describes two ways to do this. Each method has its advantages and disadvantages. Ordinarily, Anacron is run by root, but ordinary users may also use Anacron, as described in Personal Anacron use.

Obtaining and installing Anacron

Most Linux distributions include Anacron in their package sets. Thus, you can probably install the software by typing yum install anacron, apt-get install anacron, or something similar. If your distribution doesn't include an Anacron package, you need to download and install the package from source code. Unfortunately, the Anacron Web site doesn't include a link to a tarball; you need to use Concurrent Versions System (CVS) to do the job:

              
cvs -d:pserver:anonymous@anacron.cvs.sourceforge.net:/cvsroot/anacron login
cvs -z3 -d:pserver:anonymous@anacron.cvs.sourceforge.net:/cvsroot/anacron co -P anacron

After you type the first command, which logs you into the CVS repository as a guest user, you are asked for a password. Just hit the Enter key (no password is required for guest access). The second command should download the Anacron source code into a subdirectory called anacron.

One drawback to using CVS to obtain Anacron is that it can sometimes be in an unstable state. If the software doesn't compile cleanly, you can try to fix the problem yourself or wait a day or two and hope that somebody else fixes it. If you continue to have problems, you might do well to track down a precompiled binary, even if that means locating one for another distribution.

A long-standing bug in Anacron manifests itself with the message gregor.c:79: error: assignment of read-only variable 'isleap'. You can fix this bug by editing the gregor.c file's line 79 and removing the string const at the start of that line.

After you obtain the Anacron source code, you can install it by following these steps (note that you don't need to do this if you install a precompiled binary for your distribution):

1. Change into the Anacron directory created by cvs.
2. Optionally, edit the Makefile to adjust the software installation directory or other compilation details.
3. Type make to build the software.
4. As root, type make install to install the software.

After you install the software, whether by using a distribution's package management or by installing from source code, it's time to move on to configuring and running Anacron.

Configuring Anacron

Anacron is controlled through the /etc/anacrontab file. This file can contain comment lines (denoted by a leading hash mark, #), environment variable assignments (such as SHELL=/bin/bash), and job definitions. The last of these are the most important. They resemble the following:

1 5 cron.daily run-parts /etc/cron.daily

Each job definition includes four fields:

1. The run period, in days (1 in the preceding example).
2. The delay, in minutes, between the launch of Anacron and the running of the job, if the time since the last run exceeds the run period. You'll probably want to use different run delays for your jobs to prevent them all from running at once and bogging down the system.
3. A name for the job (cron.daily in the preceding example).
4. The command to run. In the preceding example, this is run-parts /etc/cron.daily.

The preceding example is intended as a replacement for the normal line in /etc/crontab that runs the daily Cron job. When Anacron is set up and running, you should be able to remove the matching /etc/crontab line and the system will continue to function normally—or function better, if the system is often shut down when the usual daily Cron job runs.

As a start for your Anacron configuration, you may want to examine /etc/crontab and convert its daily and longer entries to Anacron jobs. You should not, however, convert your hourly Cron jobs to Anacron format; Anacron isn't a suitable replacement for Cron for shorter-than-daily tasks. Precisely when the Anacron jobs run is determined by the Anacron startup method you choose, as described next.

Back to top

Running Anacron

With Anacron configured, it's time to launch it. As this is a task that must be done regularly, it's not enough for you to simply type Anacron once. Two methods of running Anacron on a regular basis are common: You can launch Anacron whenever the computer starts, or you can launch the program via a Cron job. Which method is best depends on how the computer is typically used. Ordinarily, Anacron handles system tasks, but you can also use it to handle the equivalent of user Cron jobs too, so you may want to configure it to run both types of jobs.

Running Anacron at startup

If the computer is shut down and restarted frequently (once a day or more often), then running Anacron at startup may be a good option. When the computer starts, Anacron checks for jobs that should be run and, if necessary, runs them. On a desktop computer in a typical business environment, this is likely to result in the running of Anacron jobs soon after users start their work. On a laptop computer, the run cycle might be less predictable. (Note that "startup" means a full system startup; if the computer is typically put into sleep mode rather than powered down, system startup scripts won't run, so this method won't run Anacron jobs frequently.)

To run Anacron at startup, you must create a SysV startup script to launch the software. A script to do this job can be as simple as two lines:

            
#/bin/bash
anacron

Place this script in /etc/init.d, /etc/rc.d/init.d, or wherever your distribution places its startup scripts. You can then create a link to this script in your standard runlevel's directory, such as /etc/rc3.d or /etc/rc.d/rc3.d. You should give the link a name such as S99anacron to ensure that Anacron is started when the system boots ("S" tells the system to run the script at startup, and "99" tells the system when to run it relative to other startup scripts).

If your distribution includes an Anacron package, chances are that package includes appropriate SysV startup scripts, so you need only check to be sure that Anacron runs when you start the computer. You can look for a startup script link with a name beginning with S, or you can use tools such as chkconfig or ksysv to adjust the configuration.

After you configure Anacron to run at system startup, you should keep an eye on log files and other features managed by your Anacron jobs for a few days. Check to be sure that your Anacron jobs are running at reasonable times. (Note that log files might not be rotated every time Anacron runs a log file rotation job, depending upon your logrotate configuration.)

Running Anacron from Cron

If the computer is shut down and restarted less frequently than once a day, or if you use sleep mode rather than a full shutdown, you may want to run Anacron via a Cron job. You can create an entry in your /etc/crontab file, such as the following, to do the job:

 
17 * * * * root anacron

This entry runs Anacron on the 17th minute of every hour, at which time it checks for jobs and, if necessary, runs them. Note that Anacron runs its jobs only as necessary, so running it less frequently than once an hour gains you little, unless you can predict when the system will be up—and in that case, you might as well use Cron to schedule your jobs.

When you run Anacron via a Cron job, you can't be quite sure when your Anacron jobs will run relative to the user's activities. The Anacron jobs could conceivably use up CPU time at an inopportune moment. This contrasts with running Anacron as a system startup process, when the Anacron jobs run soon after the user starts the computer.

Personal Anacron use

The preceding instructions assume that Anacron will be used to run system Cron jobs. This is often the case, but Anacron can also be run by ordinary users to manage their personal Cron jobs that should be run on a daily or longer-interval basis. The principles are all the same, but to create a personalized Anacron configuration, you must launch the program with the -t parameter, which takes the filename of a replacement configuration file, as well as -S, which specifies a directory in which Anacron stores its spool files:

anacron -t ~/.anacrontab -S ~/.anacron/

Users can place calls such as this in their personal Cron configurations, or they can use their login scripts to do the job. In either case, the spool directory must exist, and the Anacron configuration file takes the same format as it does for system Anacron jobs. As with a system configuration, the normal Cron facility should be used for hourly or other intervals that are shorter than a day.

Back to top

Summing up

Anacron is a useful tool on computers that aren't powered up 24/7. You can offload most or all of your usual daily and longer-interval Cron jobs onto Anacron, ensuring that these jobs are run every time the computer powers up or at less predictable times by running Anacron via Cron on an hourly basis (or on some other schedule).

Although it's a useful tool, Anacron has its drawbacks. Most notably, the times that Anacron runs its jobs may cause these jobs to use up CPU time or otherwise impair system performance when users want to get work done. For this reason, Anacron is best employed on systems that really need it, such as laptops and desktops that are usually powered down overnight, when Cron jobs typically run.

Resources

Learn

• The main Anacron Web page at SourceForge offers a simple description of the program.
  
  
• In the developerWorks Linux zone, find more resources for Linux developers, and scan our most popular articles and tutorials.
  
  
• "Job scheduling with cron and at" (developerWorks, July 2007) and "Controlling the duration of scheduled jobs" (developerWorks, July 2007) are two Linux tips covering job scheduling.
  
  
• See all Linux tips and Linux tutorials on developerWorks.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  

Get products and technologies

• With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.
  
  

Discuss

• Get involved in the My developerWorks community; with your personal profile and custom home page, you can tailor developerWorks to your interests and tap the knowledge of other developerWorks users.
  
  

About the author

Roderick W. Smith is a consultant and author of over a dozen books on UNIX and Linux, including The Definitive Guide to Samba 3, Linux in a Windows World, and Linux Professional Institute Certification Study Guide. He currently resides in Woonsocket, Rhode Island.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The problem
• Getting started with Anacron
• Running Anacron
• Summing up
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Linux on developerWorks

Try IBM Cognos 8 Business Intelligence

Use reports, analysis, dashboards and scorecards to monitor business performance, analyze trends and measure results.

Special offers