How to Use Anacron for Laptops and Desktops the Right Way

Cron assumes the machine is on. A laptop that sleeps through 03:00 misses the nightly job, and a desktop switched off for a week misses a week. Anacron was aimed at this: it asks "has this job run in the last N days?" and runs it if not. It does not know about clock times, which is both its limit and its strength. This post explains the format and the common setups. It is the older cousin of the catch-up feature described in systemd's Persistent option. The commands assume Debian 13 with anacron 2.3. For other schedulers, see cron syntax and launchd on macOS.

The anacrontab

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/root
LOGNAME=root

# period  delay  job-id        command
1         5      cron.daily    run-parts --report /etc/cron.daily
7         10     cron.weekly   run-parts --report /etc/cron.weekly
@monthly  15     cron.monthly  run-parts --report /etc/cron.monthly
30        20     backup.local  /usr/local/bin/backup.sh

The first number is the period in days, or @daily, @weekly, @monthly. The second is a delay in minutes after anacron starts, which spreads jobs so they do not all begin at once. The job identifier names the stamp file. A job whose stamp is older than its period runs, then the stamp is updated. A job that ran today is skipped, whatever the time.

Timestamps and testing

ls -l /var/spool/anacron/
cat /var/spool/anacron/backup.local
sudo anacron -T
sudo anacron -n -f -d backup.local

-rw------- 1 root root 9 Nov  3 03:12 backup.local
20261103

The stamp holds the date of the last run. -T tests the syntax of the anacrontab. -n runs the jobs now, ignoring the delay; -f forces them regardless of the stamp; -d keeps it in the foreground and logs to the terminal. To make a job due again, delete or edit its stamp file. A -s option runs jobs serially, which helps for heavy ones.

How Debian uses it

On Debian and Ubuntu desktops, the system cron file checks whether systemd is running; if cron cannot rely on the machine being up at the right time, jobs in /etc/cron.daily and the others run through anacron. The scripts in those directories therefore run "about once a day", and not at 06:25 sharp, as the old documentation says. When you change a schedule, edit the layout of the directories, not the cron line. On a laptop, anacron also checks the power: it skips jobs on battery unless you pass -d or change its default behavior in the distribution's wrapper.

Anacron for one user

mkdir -p ~/.anacron/etc ~/.anacron/spool
echo '1 10 mybackup  $HOME/bin/backup.sh' > ~/.anacron/etc/anacrontab
crontab -l 2>/dev/null; (crontab -l 2>/dev/null; echo '@hourly /usr/sbin/anacron -s -t $HOME/.anacron/etc/anacrontab -S $HOME/.anacron/spool') | crontab -

Anacron is started by a regular cron entry that runs often, here hourly, and decides by itself whether any job is due. Users without root keep a private anacrontab and spool directory and point anacron at them with -t and -S. The trigger should fire at login or at boot too; cron's @reboot covers that.

Where this does not apply

Anacron cannot do "every day at 09:00". It only guarantees that a daily job runs once per day. On systemd systems, a timer with Persistent=true and an OnCalendar time gives the same catch-up and a time of day, plus logging; see converting cron to timers. Servers that are always on do not need it. Jobs must tolerate running at an unpredictable moment, such as in the middle of work.

What anacron promises and what it does not

Anacron runs periodic jobs on machines that are not on all the time. Cron fires a job only if the machine is up at that minute, so a laptop closed overnight misses its nightly tasks. Anacron works from a different idea: it records the date each job last ran, and when it starts, it runs any job whose period has elapsed, after a configured delay. Its resolution is days, not minutes, so it handles daily, weekly and monthly jobs and cannot do "every ten minutes" or "at 03:15". It does not run as a background scheduler by itself. Something has to start it, usually a boot script, a cron entry or a systemd unit, and then it runs the due jobs and exits. This makes it an excellent fit for backups, log rotation and maintenance on desktops and laptops, and the wrong tool for anything that needs a particular time of day or runs more often than daily.

On a modern systemd machine, a timer with Persistent=true gives the same catch-up behavior, so anacron is mostly relevant for systems without systemd, for the way some distributions run their daily cron jobs, and for users who want a personal catch-up scheduler.

Each field of an anacrontab line

A line in /etc/anacrontab has four fields: the period in days, the delay in minutes after anacron starts, a job identifier used to name the timestamp file, and the command. The period can be a number or the names @daily, @weekly and @monthly, and the monthly form means once per calendar month. The delay staggers jobs so they do not all start at once when the machine boots, and a random delay can be added through the RANDOM_DELAY variable at the top of the file. The identifier must be unique, since it names the stamp file in /var/spool/anacron/, and two jobs sharing one never both run. The START_HOURS_RANGE variable restricts jobs to certain hours, so a heavy job does not start in the middle of someone's workday. Output goes to mail, as with cron, so set MAILTO or redirect.

Check syntax with anacron -T, which validates the file without running anything. To run jobs now, ignoring the delay, use anacron -n, and -f forces them regardless of the timestamps.

Debugging a job that did not run

Look at the timestamp files first. If the file for the job holds today's date, anacron believes it already ran, and will not run again until the period passes. Remove or edit the file to test, or use -f. Check that anacron itself starts at boot and, on Debian-style systems, remember that the cron daily jobs run through anacron only when the package is installed and the machine is not always on, a detail that depends on how the distribution wires /etc/cron.daily. A job that runs but fails does not retry until the next period, so watch its output and exit status. Test commands by running them by hand under a minimal environment, because anacron gives jobs the same plain environment as cron. For a personal setup without root, run it with your own table and spool directory: anacron -t ~/.anacrontab -S ~/.anacron-spool from a login script, which gives per-user catch-up jobs with no system changes.

Choosing between anacron and a timer

Where systemd is available, a timer with Persistent=true and a randomized delay does what anacron does, with more precision and better logging, and it needs no extra package. Anacron remains useful on systems without systemd, in minimal containers that already ship it, and for people who like the one-file table of periodic jobs. If you run both for the same job, you will get it twice, so pick one. When you migrate a job from anacron to a timer, remove the anacrontab line and delete its stamp file, then check systemctl list-timers after the first scheduled day to confirm the new job ran. Whichever you use, keep the commands short, call a script by full path, and write the output to a log file, since a laptop job that fails while you are away has nobody to tell.

See anacron(8) and anacrontab(5).