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
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.
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,
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:
Listing 1. Downloading Anacron from CVS
cvs -d:pserver:firstname.lastname@example.org:/cvsroot/anacron login cvs -z3 -d:pserver:email@example.com:/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
You can fix this bug by editing the gregor.c file's line 79 and removing
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):
- Change into the Anacron directory created by
- Optionally, edit the
Makefileto adjust the software installation directory or other compilation details.
maketo build the software.
make installto 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.
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:
Listing 2. Sample job definition
1 5 cron.daily run-parts /etc/cron.daily
Each job definition includes four fields:
- The run period, in days (
1in the preceding example).
- 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.
- A name for the job (
cron.dailyin the preceding example).
- The command to run. In the preceding example, this is
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
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
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:
Listing 3. Startup script to run 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
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
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
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:
Listing 4. Cron job to run Anacron
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
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.
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.
- 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.
- 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.
Dig deeper into Linux on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.