While cron is the classic standby to run routine tasks on a regular basis, it's not quite as useful on systems (like laptops and desktops) that may not be powered on when the task is scheduled to run. Fortunately, Linux users have anacron to fill the gap left by cron.
Linux (like Unix) relies on cron to run certain tasks on a regular basis. Typically, a Linux system uses a series of directories (/etc/cron.daily, /etc/cron.hourly, and so on) to store scripts you want to be run at specific times. Precisely when they’re run is determined by /etc/crontab. Ordinary users and the system administrator can also create individual cron jobs. This mechanism is useful for running programs that perform routine maintenance — to prune /tmp, rotate log files, look for software updates, and so on.
Unfortunately, cron has an Achilles Heel: It can’t run if the computer is turned off. Although most servers run continuously, many computers, including most laptops and many desktop systems, don’t. These systems are often powered off more than they’re powered on to save energy. Unfortunately, many important cron jobs are routinely scheduled to run in the dead of night (usually between midnight and 6:00 am) to avoid conflicts with user tasks. This is precisely the time when laptops and desktops are most likely to be shut down. Hence, cron jobs don’t run and the results are log files growing out of control, increased clutter in /tmp, among other detrimental effects.
Fortunately, there’s armor for cron’s Achilles Heel: anacron. This utility, which ships with most Linux distributions, can run a program if it hasn’t run within a specified period of time. Configured appropriately, anacron can plug the hole left when cron doesn’t run late at night, by running your usual cron jobs when you power up a computer or at other times that you specify — but only if necessary, thus avoiding unnecessary delays if you shut down and boot up a computer several times a day.
Obviously, anacron is most useful on laptops, desktops, and other computers that are often shut down when daily and longer-period cron jobs would ordinarily run. anacron is less useful on servers and other systems that routinely run 24/7. anacron also doesn’t handle cron jobs that run at hourly or other shorter-than-daily intervals, and for this reason should be considered a supplement to, rather than a replacement for, cron.
Most distributions provide an anacron package called, appropriately enough, anacron. Thus, the easiest way to install the program is usually to install your distribution’s package. Consult your distribution’s information if you need guidance.
If you can’t find a distribution-specific anacron package, you can download the source code from its Web site, http://sourceforge.net/projects/anacron. The source package is less user-friendly than most, though: it lacks a configure script or similar facility, and instead relies on your ability to manually edit the Makefile and even one source code file to customize the package for your system. Fortunately, because most distributions provide anacron binary packages, chances are you won’t need to deal with the source package.
Setting Up anacron Jobs
The main anacron configuration file is /etc/anacrontab. This file is the equivalent to cron’s/etc/crontab: It specifies what programs to run and how often to run them. Unlike a crontab file, though, the anacrontab file doesn’t specify exact times at which commands should be run. Instead, anacrontab specifies the frequency, in days, with which the job should be run. If, when you run anacron, its internal bookkeeping indicates that it hasn’t run a job in more than the specified number of days, anacron will run that job.
Like crontab, the /etc/anacrontab file contains comments (lines that begin with a hash mark, #), variable assignments, and time specifiers. Listing One is a sample /etc/anacrontab file, taken from a Gentoo system. Listing One‘ s anacrontab is designed to enable anacron to function as a drop-in supplement for cron. It sets a couple of important environment variables (SHELL and PATH; the latter is important for the benefit of scripts that don’t specify complete paths to the external programs they call), a comment line describing the meaning of each field, and three lines telling anacron to run jobs on a daily, weekly, and monthly basis.
The frequency, or period, to run the command. This period is specified in days, a fact that makes anacron useful for jobs that should be run on a daily or less frequent basis, but not so useful for jobs that should be run more frequently.
The delay period, specified in minutes, between the time that anacron is started and the time that the job should run. This delay period helps prevent a logjam when you start the computer, should you choose to launch anacron at that time. If you have multiple job lines, as Listing One does, it’s a good idea to specify different delay times for each one, to minimize the risk of anacron jobs competing with each other for CPU time and other system resources.
The job identifier is a name that’s associated with each job. You can specify anything you like for the job identifier, so long as it doesn’t include spaces. Listing One uses descriptive identifiers based on the cron subdirectory that each job manages. The job identifier can optionally be used in calls to the anacron program to have anacron run only the specified jobs. (I don’t describe such configurations in any detail in this column, though.)
Everything after the job identifier is the anacroncommand. In the case of Listing One, this is run-parts followed by a directory. The run-parts command, which is also used by many distributions’ default cron configurations, runs all the scripts in a specified directory.
The net effect of Listing One is to take over the daily, weekly, and monthly cron jobs by running the scripts in the relevant cron directories. Most distributions have an /etc/crontab file that calls run-parts in much the same way as specified by Listing One; however, cron does so at precisely specified times, such as 5:30 AM on the first day of each month for the monthly task.
Although Listing One (or any similar configuration file that was probably installed on your system when you installed your anacron package) is a good starting point, you might want to tweak things. The easiest approach drop a script into the appropriate cron scripts directory (such as /etc/cron.daily, /etc/cron.weekly, or /etc/cron.monthly). Your script then runs with the appointed frequency. If you want your script to run at some other frequency, you can create your own entry in /etc/anacrontab. For instance, you could use the following line to run a script once every two weeks:
14 20 anacron.2weeks two-weeks
This line, added to the end of Listing One, runs the two-weeks script once every fourteen days. The delay period is set to 20 minutes, 5 minutes more than the longest delay period in the original Listing One, to avoid conflicts.
anacron doesn’t care about the day of the week or the day of the month; if you want a job to run on the first of the month and not the second, anacron isn’t the right tool for you to use. In fact, even if a system were left up 24/7 for months, with anacron being run regularly during that time, the day of the month on which monthly anacron jobs run would drift because of the differing number of days in each month. Similarly, the weekly anacron job in Listing One could run on different days of the week if the computer were shut down for a day or two over a period that would normally see a run.
Fortunately, such drift isn’t important for most of the standard cron jobs you might want to entrust to anacron. You should be aware of this fact in case you want to deploy anacron on a system that runs jobs that might be more sensitive to actual calendar dates, though. For instance, you wouldn’t want to generate payroll checks automatically using an anacron job.
Because most distributions provide default anacron configurations that take over some cron duties, you may want to remove the standard cron entries for the equivalent tasks from the cron configuration file, /etc/crontab. To avoid running the daily, weekly, and monthly cron jobs twice, you should comment out the relevant lines from this file — the ones that reference the same scripts or, when run-parts is called, the same subdirectories (such as /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly).
Of course, to do any good, anacron must run periodically. The best schedule depends on how the computer is to be used and your own needs and preferences. Let’s look at two methods here: Running anacron at boot time and running it via cron.
Running anacron at Boot Time
If the computer is completely shut down and restarted on a regular basis, running anacron when the system is first booted can be a useful approach. You might use this method for a desktop or laptop system that’s shut down daily. The drawback is that users typically boot a computer just before they begin using it, so the anacron jobs can end up running when the user wants the computer to be responsive. You can mitigate this negative effect by setting an appropriate delay parameter for each of the anacron jobs. For instance, if the user regularly takes a break two hours after booting the computer, a delay period of 120 minutes would, with luck, coincide with this break period.
To run anacron at boot time, create a System V init script or call anacron in a local boot script. The details of how to do these things vary from one distribution to another. Most distributions that provide anacron packages also provide SysV init scripts; however, these scripts might not be active by default. In many distributions, you can use chkconfig to check the status of your init scripts:
chkconfig ––list | grep anacron
If you see output beginning with anacron, you can determine whether anacron is configured to run at boot time for your default runlevel (typically 3 or 5). If it’s not, use chkconfig ––add option to add it:
chkconfig ––add anacron
Not all distributions use chkconfig, though. Other tools you might try include ntsysv, YaST, sysv-rc-conf, and rc-update. Check for these tools and read the package’s documentation or documentation on your distribution’s SysV startup script management for details on how to use them.
Instead of using a SysV startup script, you can call anacron in a local startup script. This approach is most likely to be useful if you compiled anacron from source code or if your distribution’s package didn’t include a SysV startup script. Most distributions provide local startup scripts, but their names differ. Some popular ones include /etc/rc.local, /etc/rc.d/rc.local, /etc/init.d/boot.local, and /etc/conf.d/local.start. If you can’t find any of these files on your system, try searching for any file in the /etc directory tree with the word local in its filename. Once you’ve located the appropriate startup script file, add a call to the anacron program file in that script. Typically, you needn’t specify any options to anacron; the defaults do the right thing.
Running anacron via cron
Sometimes it’s desirable to run anacron via cron. This may seem like an odd choice; after all, if cron is unreliable because the computer is often powered off or in sleep mode, why use cron to run anacron jobs? There are several reasons why this approach is desirable. One is that the computer might not be powered down regularly — it might be in sleep mode rather than off or it might be shut down at irregular intervals. Another reason to use cron is to run anacron jobs at particular times, such as during an office worker’s lunch break.
To run anacron via cron, you must create a custom cron job. You would most likely begin by editing the /etc/crontab file, as described earlier, to remove the normal cron entries for the tasks that anacron will perform. You would then create an /etc/crontab entry to run anacron:
00 12 * * * root /usr/sbin/anacron
The /etc/crontab file’s entries consist of a five-field time specifier, the username that’s to run the process, and the command to run. Normally, you’ll specify root as the user and anacron (possibly including its path) as the command.
The time specification consists of the minute, the hour (in 24-hour format), the day of the month, the month, and the day of the week. An asterisk (*) in any field means that any time matches. Thus, the preceding example runs anacron at 12:00 noon every day. You can use more complex specifications, using comma-separated lists, dash-separated ranges, and slash-specified repeating intervals. For instance:
00 */3 * 1-11 1,2,3,4,5 root anacron
This entry runs anacron every third hour (*/3), January through November (1-11), on every weekday (1,2,3,4,5; for the day of the week, 0 and 7 both refer to Sunday and 1 through 6 refer to Monday through Saturday). Because this entry specifies January through November, anacron won’t run at all in December. Chances are an entry like this won’t be very practical, though; it simply demonstrates some of the tools available for specifying times in cron.
When running anacron via cron, chances are you’ll use short delay times in your /etc/anacrontab file. You’ll probably want to run anacron at least once a day, and perhaps more often, depending on the computer’s use patterns — more frequent runs make sense if the computer is likely to be shut down or put into sleep mode frequently. Running anacron several times a day isn’t normally a problem; anacron will run its jobs the first time it runs, provided the system isn’t shut down before an anacron job’s delay time. On subsequent runs, anacron will quickly determine that it needn’t do anything, so the impact on system performance will be trivial.
With the basics of anacron configuration under your belt, you should be able to ensure that vital, regular maintenance tasks are performed even on desktop systems and laptops that are frequently powered down when Linux traditionally runs cron jobs. You may want to experiment with different methods of running anacron to discover what works best for you, with minimal disruption to your use of the computer.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62