VMware ESXi and vSphere Cluster Management

Schedule Periodic Jobs with anacron in Linux

Learn how anacron runs day-based Linux maintenance jobs after intermittently powered computers become available, including configuration, timestamps, testing, and safety.

anacron is a Linux utility for running periodic commands when a computer is not guaranteed to remain powered on. Instead of requiring a command to run at an exact clock time, anacron checks whether a job's day-based interval has elapsed. If the job is due, anacron runs it after the system becomes available.

This makes anacron useful for laptops, desktops, and other systems that may be shut down or asleep when scheduled maintenance would otherwise occur.

How anacron differs from cron

cron is a time-based scheduler. Its schedules can specify exact minutes, hours, days of the month, months, and days of the week. If a computer is powered off when a cron job's scheduled clock time passes, that job does not normally run later simply because the computer starts.

anacron uses periods measured in days rather than detailed minute, hour, and calendar expressions. It records completed jobs with timestamp files. When anacron next runs, it checks those records and launches jobs whose periods have elapsed. In this way, a due periodic task can run after startup or another scheduled invocation of anacron.

Administrative access and configuration

The system-wide anacron configuration file is /etc/anacrontab. Editing this file and running system-wide anacron jobs commonly require root-level privileges. A user with appropriate administrative access normally uses sudo when editing the file or testing anacron.

anacron is generally started by a system startup mechanism or by a scheduled invocation. The exact mechanism depends on the Linux distribution and its system configuration. The important behavior is that anacron must run periodically or at startup so it can inspect timestamp records and launch jobs that are due.

anacrontab job syntax

A job line in /etc/anacrontab has this structure:

PERIOD DELAY JOB-IDENTIFIER COMMAND

The fields are separated by whitespace. The COMMAND field occupies the remainder of the line, so it may contain the shell command and its arguments.

PERIOD

PERIOD is the number of days between eligible executions. It does not specify a particular time of day. For example, a period of 1 means daily, while 7 means weekly.

DELAY

DELAY is measured in minutes. It tells anacron how long to wait after anacron starts before launching that job. A delay can help avoid starting several maintenance commands immediately during system startup.

JOB-IDENTIFIER

The JOB-IDENTIFIER is a unique name for the job. anacron uses this name when maintaining the job's execution record. Every job should have a distinct identifier so separate jobs have independent timestamp tracking.

COMMAND

The COMMAND is the shell command or script that anacron executes. Because it occupies the remainder of the line, include the complete command and its arguments after the first three fields.

Timestamp tracking

anacron uses a timestamp file to remember when each job last ran. These records are stored under /var/spool/anacron. When anacron starts, it compares each job's period with its timestamp. If enough time has passed, the job is considered due and can be launched after its configured delay.

The job identifier connects an anacrontab entry with its timestamp record. Reusing an identifier for different jobs can make them share or conflict over execution tracking. Give every job a unique identifier.

Example: a daily maintenance job

The following entry describes a daily cleanup command that waits three minutes after anacron starts:

1 3 rm.command rm /home/bob/tmp/*

Before using this example, verify that /home/bob/tmp/ is the intended controlled temporary directory. The pattern * can match many entries, and rm is destructive. First inspect the intended selection with a non-destructive command, such as:

printf '%s\n' /home/bob/tmp/*

Check the path, spelling, permissions, and wildcard behavior before placing a removal command in /etc/anacrontab. Use a narrowly scoped directory and avoid testing a destructive wildcard against an important path.

Adding and testing a job

1. Plan the interval, startup delay, unique identifier, and command.
2. Validate the command and all file paths independently. For cleanup work, inspect wildcard matches before using a deletion command.
3. Edit the system-wide configuration with suitable administrative access and add the job to /etc/anacrontab.
4. Ensure the job identifier is not already used by another entry.
5. Run anacron manually in foreground/debug mode:

sudo anacron -d

The -d option lets you observe anacron's behavior directly. Use the output to determine whether jobs are detected as due, whether their delays are applied, and whether commands are launched. A job that has run recently may not be due during every test; its timestamp record controls eligibility.

After testing, allow the system's normal startup or scheduled invocation mechanism to run anacron. A manual run is useful for diagnosis, but it does not replace the mechanism that normally starts anacron.

Troubleshooting

The task did not run while the computer was powered off

A time-specific cron schedule was probably used. cron does not normally replay a missed clock time after startup. For eligible daily or other periodic work, use anacron and ensure anacron runs when the system becomes available.

An anacron job is not recognized as due

Check the job's timestamp record and confirm that its period has elapsed. Also verify that the job identifier is unique. Two entries with the same identifier can interfere with independent timestamp tracking.

The job starts later than expected

Review the DELAY field. The value is an intentional number of minutes to wait after anacron starts. For example, a delay of 3 postpones execution by approximately three minutes after that anacron invocation.

Configuration changes cannot be saved

System-wide configuration normally requires root-level privileges. Confirm that you are editing /etc/anacrontab with appropriate administrative access and that the file contains correctly separated fields.

The cleanup job removes unexpected files

The path or wildcard pattern may be too broad. Test file selection without deletion, inspect the result carefully, and narrow the directory or pattern. Never assume that a wildcard matches only the files you intended.

Key points

• anacron runs commands at day-based intervals.
• It is designed for systems that may be off or unavailable when maintenance would otherwise be scheduled.
• It records completed jobs and runs due jobs when anacron next runs.
• The system-wide configuration file is /etc/anacrontab.
• Each job uses PERIOD DELAY JOB-IDENTIFIER COMMAND.
• Timestamp records are stored under /var/spool/anacron.
• Every job identifier must be unique.
• Use sudo anacron -d to observe a manual foreground/debug run.
• Validate paths and wildcard patterns carefully before scheduling destructive commands.

For a related scheduling topic, see Schedule Jobs With Anacron.