Easy Guide to anacron Command in Linux

The anacron command in Linux can catch "silent failures" such as the one described above. A user had a cron job running nightly with no issues for about 3 months. The server received a kernel update which caused the server to restart late in the week (Thursday) but none of the other admins knew that the backup scripts did not run after the restart. This type of "silent failure" is exactly what anacron was created to detect.

In my experience I've seen many instances where a job has been set to run via cron. When the system came back online (i.e. either the clock struck midnight or when the admin restarted the box), the job simply went away. In contrast, if anacron is being used, the job simply runs as soon as the box comes back online without further prompting from the administrator.

This tutorial is designed for anyone who uses/needs to use scheduled tasks on their systems (sysadmins, DevOps engineers etc.) regardless of how much they know about Linux. Once you complete reading through this tutorial, you'll be able to create, test & troubleshoot your own anacron jobs on both Ubuntu, RockyLinux and Red Hat Enterprise Linux.

Examples

Anacron is a Linux job scheduler used to run commands periodically, measured in days. Unlike cron, which strictly follows the system clock and scheduled execution time, anacron focuses on whether enough time has passed since the job last ran. This makes it especially useful on systems that are not powered on continuously.

A simple way to understand the difference is this: cron behaves like a clock alarm. If the alarm goes off while the system is powered off, the task is missed completely. Anacron behaves more like a reminder note. It checks whether a job was missed and runs it automatically the next time the system becomes available.

Technically, anacron reads its configuration from /etc/anacrontab and checks timestamp files stored under /var/spool/anacron. For each configured job, it determines whether enough days have passed since the last successful execution. If the answer is yes, anacron waits for the configured delay (measured in minutes), executes the command, and then updates the timestamp file with the current date so it knows when the job should run again.

This makes anacron the right tool for desktops, developer workstations, laptops, and any server that gets rebooted regularly. Things like weekly database dumps, monthly log cleanups, daily backup scripts, these all belong in anacron rather than cron if there is any chance the machine will be off at the scheduled hour. You can also check our Linux automation guide for 2026 for broader context on scheduling strategies.

One thing worth knowing upfront: anacron only goes down to day-level granularity. If you need something to run every hour or every 15 minutes, that is cron territory. Anacron is for daily, weekly, monthly, or any N-day interval jobs where exact timing is less important than guaranteed execution.

The anacron command itself has a straightforward syntax:

The real configuration lives in /etc/anacrontab. Each job line follows this four-field structure:

Breaking down each field: the period is how many days between runs. Use 1 for daily, 7 for weekly, 30 for monthly, or any number you need. The delay is how many minutes to wait after anacron starts before actually running the job. This prevents everything from slamming the CPU at once right after boot. The job-identifier is just a unique name used in log files and to name the timestamp file in /var/spool/anacron. The command is whatever you want to run.

Two environment variables in anacrontab are worth knowing: START_HOURS_RANGE defines the window of hours during which anacron will start jobs (for example, 3-22 means jobs only start between 3 AM and 10 PM). If your machine powers on or anacron is triggered outside this range, say at 11:30 PM during a late maintenance window, anacron sees it is outside the allowed hours and exits immediately without running anything. Jobs wait until the next time anacron runs inside the defined range. RANDOM_DELAY adds a random number of minutes on top of your defined delay, which is useful on shared or busy systems where you do not want multiple jobs stacking up at the same instant.

Before adding anything new, look at what is already in anacrontab. On most systems, the default file handles daily, weekly, and monthly cron directory sweeps already.

On most Ubuntu and Debian systems anacron comes pre-installed, but if it is missing this installs it.

This is the most common use case. Edit anacrontab to add a daily backup script that will run whenever the machine is on, even if it missed the original scheduled time.

Any time you edit /etc/anacrontab, run the syntax check before walking away. A bad line does not produce an error at edit time, only when anacron tries to execute.

Exit code 0 means the syntax is clean. Exit code 1 means there is an error and anacron will also print which line is the problem.

When setting up a new job, you do not want to wait days to verify it actually works. The -f -n -d combination forces all jobs to run right now with output on screen.

The timestamp files in /var/spool/anacron are how anacron tracks job history. Checking them tells you exactly when each job last executed.

After doing manual maintenance or running jobs by hand, you want to reset the timestamps so anacron does not run them again immediately after. The -u flag updates the dates without executing anything.

Regular users can run their own anacron setup using a custom anacrontab and a private spool directory. This is useful for developer workstations or personal automation tasks that should not be in the system-wide config.

A real-world production task: clean up application logs older than 30 days every week. Drop the script into /etc/cron.weekly or add it directly to anacrontab for guaranteed execution. Note: if you are following along exactly, run sudo mkdir -p /var/log/myapp first so the find command has a valid target to work with.

You can tell anacron to run only one specific job from the anacrontab by passing its job identifier as an argument. Useful when you want to test or re-run just one entry without triggering everything.

This is the silent failure that catches people. The default shell in anacrontab is /bin/sh, not /bin/bash. If your script uses bash-specific syntax (arrays, [[ ]], string operations), it will fail or behave unexpectedly when called through sh.

If you have multiple resource-intensive jobs in anacrontab and they pile up at startup after a long downtime, the -s flag makes sure they run one at a time. Anacron processes jobs sequentially by default when reading a standard anacrontab, but -s enforces this as a hard guarantee even if the environment or an external script tries to spawn anacron asynchronously. Think of it as a lock, not just a preference.

Most Linux users do not realize how often scheduled cron jobs fail silently. The system may have entered sleep mode, rebooted during maintenance, or simply been powered off before the scheduled runtime. A laptop lid closed at 11:55 PM is enough to prevent a midnight cron job from running. Cron does not warn you about missed executions. You usually discover the problem much later, often when you actually need the backup or maintenance task that never completed.

Anacron changes that behavior completely. Instead of following a strict “run exactly at midnight” model, anacron focuses on ensuring the task runs once within the required time period whenever the system becomes available again. For most maintenance tasks, that is usually the behavior administrators actually want. What matters is that the backup, cleanup, or maintenance task ran successfully today, not necessarily that it executed at precisely 12:00 AM.

This becomes even more important in enterprise and production environments. Servers are regularly rebooted for kernel patching, hardware maintenance, virtualization migrations, or cloud infrastructure updates. If cron jobs are scheduled during those maintenance windows, the executions are skipped entirely. Missing cleanup routines, backup jobs, certificate renewals, or database maintenance tasks can quickly create larger operational problems. Anacron helps make these scheduled jobs far more reliable without requiring you to rewrite the scripts themselves. In most cases, the only change required is registering the task through anacron instead of cron. If you are building a more reliable backup workflow, the Linux server backup strategies guide covers additional enterprise backup planning and automation practices in more detail.

There is also the quieter benefit: anacron reduces the anxiety around scheduled tasks. You stop having to wonder "did the weekly cleanup actually run this week?" and start actually knowing. The timestamp files in /var/spool/anacron give you a simple audit trail. You can inspect them any time with a quick cat and see exactly when each job last ran. That is the kind of operational visibility that saves you headaches at 2 AM. For more on building reliable automation in Linux, the automatic Linux backup script guide pairs well with what you have learned here. The official reference is the anacron man page on man7.org if you want to go deeper on any specific flag or behaviour.