Linux online course

Schedule Periodic Jobs with Anacron on Linux

Learn how Anacron schedules day-based maintenance jobs, handles missed runs, uses delays and timestamps, and differs from cron on Linux.

Anacron is a Linux utility for running periodic jobs based on elapsed days. It is designed for laptops, desktops, and other systems that may be powered off or asleep when maintenance would normally run.

Unlike a fixed-time scheduler, Anacron does not try to run a command at an exact clock time. When Anacron is invoked and a job is overdue, the job becomes eligible to run while the system is available.

What Anacron is for

Anacron is useful for recurring maintenance such as cleanup, cache refreshes, backups, and reports that should happen approximately daily, weekly, or monthly even when the machine is not continuously running.

For example, suppose a laptop is shut down at the time a daily task would normally run. When the laptop starts and Anacron is invoked, the task can be recognized as overdue and run after its configured delay. The run is based on the elapsed time since the recorded execution state, not on a particular clock time.

Anacron complements cron; it does not replace it for every scheduling problem. Cron is better when a command must run at a precise time, several times per day, or at a frequency shorter than one day.

Anacron versus cron

Cron is a time-based scheduler. A cron entry describes calendar and clock fields such as minute, hour, day of month, month, and weekday. If the machine is off when a cron event is due, that event is ordinarily missed and is not automatically made up.

Anacron uses whole-day periods and persisted state. If a periodic job is due when Anacron next runs, it can catch up after boot or another invocation. The result is not an exact calendar appointment: a seven-day job is not necessarily every Monday.

Modern distributions may also use systemd timers. Some provide daily, weekly, and monthly timer units that offer behavior similar to traditional Anacron integration. Check which scheduler actually owns a task before adding a duplicate job.

The system-wide Anacron configuration

The commonly used system-wide configuration file is /etc/anacrontab. It may contain comments beginning with #, blank lines, global settings, and job entries. The exact defaults and supported settings vary by distribution and Anacron implementation.

Common settings include:

Because distributions may invoke Anacron through cron, systemd, or startup services, the configuration file alone does not prove that Anacron is being run.

Anacron job entry syntax

A standard job entry has four whitespace-separated fields:

period-in-days delay-in-minutes job-identifier command

For example:

1 3 cleanup-tmp /usr/local/sbin/cleanup-tmp

This means that the job is eligible every day, waits three minutes after Anacron starts, uses cleanup-tmp as its state identity, and runs the executable at the absolute path shown.

The command field can include arguments and, where supported by the implementation, shell syntax. Complex quoting, pipelines, conditionals, and destructive operations are easier to review in a separate script. Every job identifier must be unique because it maps the entry to persisted timestamp state.

Periods, delays, and execution timing

A period is a whole-day interval:

• 1 means approximately daily.
• 7 means approximately every seven days.
• 30 means roughly monthly; it does not mean a calendar month.

The period is measured from recorded successful execution state. A period of 7 does not mean “every Monday.” If the job runs on Wednesday, its next eligibility is determined from that recorded state.

The delay is different from the period. A delay is measured in minutes after Anacron starts. It can prevent maintenance from competing immediately with boot services, disk activity, and user login.

7 15 refresh-package-cache /usr/local/sbin/refresh-package-cache

This weekly job waits 15 minutes after Anacron starts. The script should tolerate an unavailable network and write useful diagnostics. If several jobs are due, their individual delays, processing order, and any configured RANDOM_DELAY affect observed start times. Choose delays that reduce the chance that expensive jobs overlap. Randomization can further spread starts, but it does not provide an exact schedule.

Timestamp files and job state

Anacron records execution state in timestamp files, commonly under /var/spool/anacron. A job identifier such as cleanup-tmp is associated with a corresponding timestamp identity, commonly represented by a file with that name in the spool directory.

sudo cat /etc/anacrontab
sudo ls -l /var/spool/anacron/

When Anacron runs, it compares the timestamp state with the configured period to decide whether a job is due. System configuration and spool state are normally administered by root.

• Changing a job identifier creates a new timestamp identity. The replacement can be treated as new or due because it has no matching previous state.
• Removing a timestamp can cause the job to be considered due again.
• Editing stored state can change when Anacron considers the job eligible and should be done only deliberately.
• Do not delete timestamps casually on a production system; understand the resulting catch-up behavior first.

Privileges, ownership, and security

System Anacron jobs generally run with root privileges. Protect /etc/anacrontab, the spool directory, and every script executed by root with appropriate ownership and permissions. A root-run script must not be writable by an untrusted user.

Ordinary users normally use user crontabs or user-level systemd timers rather than editing the system Anacron configuration. Choose the least privilege needed for the task.

• Use absolute paths for programs and important files. The scheduled environment may have a limited PATH.
• Set required environment variables explicitly instead of relying on interactive shell startup files.
• Quote variables safely and validate their contents before using them in commands.
• Avoid broad privileged commands such as unsafe wildcard deletion. Fixed paths, checks, age restrictions, and logging are safer.
• Use a controlled interpreter line such as #!/bin/sh or #!/bin/bash when appropriate, and verify executable permissions.

Reliable job design

Put nontrivial work in a dedicated executable script. Test the script manually before scheduling it, and make it idempotent: safe to run again without causing unintended additional effects. This matters because a job may run late or be retried after a failure.

1 10 rotate-app-data /usr/local/sbin/rotate-app-data >> /var/log/rotate-app-data.log 2>&1

This captures standard output and standard error in one log. The log must be writable by the execution user and should itself be rotated to prevent uncontrolled growth.

For destructive cleanup, prefer a reviewed script with behavior such as:

1. Validate that the intended directory exists.
2. Use a fixed absolute directory path.
3. Restrict deletion to the intended file types and, when appropriate, files older than a defined age.
4. Log what was removed.
5. Return meaningful exit statuses.

Long-running work may overlap with a later invocation or another maintenance task. Use a lock such as flock where available, or implement another reliable overlap-prevention method. If exact windows or complex dependency ordering are required, a systemd timer and service may be a better fit.

Starting and invoking Anacron

Distributions commonly invoke Anacron automatically through a startup mechanism, cron integration, or systemd. To investigate or test it interactively:

anacron --help
man anacron && man anacrontab
sudo anacron -d

The -d option commonly enables debug or foreground behavior, but flags differ among implementations. Some versions support options for dry runs, forced execution, or updating state without running commands. Consult the installed manual page before using such options.

Do not assume that manually running Anacron permanently enables it. Manual execution is useful for diagnosis; normal operation still depends on the distribution's service, timer, or cron integration.

Validation and troubleshooting

First checks

command -v anacron
anacron --help
sudo cat /etc/anacrontab
sudo ls -l /var/spool/anacron/
systemctl list-timers --all
journalctl -b | grep -i anacron

Confirm that the package is installed, identify the actual binary, verify the configuration path, and determine whether systemd, cron, or another service invokes Anacron. Check local manuals because paths and integration vary.

A job did not run after boot

• The job may not yet be due according to its timestamp.
• Its configured delay or random delay may not have elapsed.
• The current time may be outside START_HOURS_RANGE.
• Anacron may not have been invoked.

Run sudo anacron -d, inspect the relevant timestamp, review /etc/anacrontab, and check systemd timers, service units, or cron integration.

A changed job runs as if it were new

Compare the configured identifier with the files in /var/spool/anacron. A changed identifier creates a different state identity. A missing or unreadable timestamp can have a similar effect. Restore or reset state only after deciding whether an immediate catch-up run is safe.

The command works interactively but fails under Anacron

• Use absolute executable and file paths.
• Set required environment variables explicitly.
• Do not depend on the interactive working directory, aliases, shell startup files, or user credentials.
• Check script ownership, permissions, and the interpreter line.
• Redirect output and errors to a managed log.

No email or log output appears

Output may be redirected elsewhere, MAILTO may be unset, local mail delivery may be unavailable, or the command may produce no output. Add explicit logging, inspect the journal and mail logs where available, and run the command manually to verify its diagnostics.

Jobs overlap or cause a startup load spike

Stagger individual delays, use RANDOM_DELAY when appropriate, and add locking to long-running scripts. If the work needs an exact low-load time window, move it to a scheduler that supports that requirement.

Choosing a scheduler

Exam-relevant points

• Anacron schedules by elapsed whole days, not exact clock times.
• The period and delay are different: the period controls eligibility; the delay controls how long Anacron waits after starting.
• A missed cron event is ordinarily not made up, while an overdue Anacron job can run after the next invocation.
• The job identifier links a configuration entry to timestamp state, commonly under /var/spool/anacron.
• Changing or deleting timestamp identity can make a job appear new or due.
• Use safe, absolute-path, root-owned scripts for privileged maintenance.
• Check local manuals and scheduler integration because Anacron options and defaults vary by distribution.