Learning Cron Job - Anacron & System Cron Dirs

#Introduction

In episode 7 we built a debugging discipline. Now we cover two components that complement cron for special cases: anacron for machines that are often off, and system cron directories for scheduling interval-based scripts.

Imagine a laptop you use from 09.00-18.00, then let sleep at night. Pure cron will miss the 02.30 job while the laptop is asleep — and never catch up on it. Anacron exists to close this gap.

#Anacron: Running Missed Jobs

#The Concept

Anacron tracks when a job last ran, not what time it was scheduled for. If a job should have run yesterday but the machine was off, anacron runs it as soon as the machine is active — regardless of what time it is now.

Anacron 2.3
Updated timestamp for job `cron.daily' to 2026-08-12

#The /etc/anacrontab Configuration

The /etc/anacrontab format differs from crontab:

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
RANDOM_DELAY=45
START_HOURS_RANGE=3-22
 
1       5       cron.daily      run-parts /etc/cron.daily
7       10      cron.weekly     run-parts /etc/cron.weekly

Four fields per line:

1. period — days (1 = daily, 7 = weekly).
2. delay — minutes to wait after the machine is active before running.
3. job-id — a unique name for timestamp tracking.
4. command — the command to run.

RANDOM_DELAY and START_HOURS_RANGE spread the load when many jobs are waiting.

#Anacron Timestamps

Anacron stores when each job last ran:

/var/spool/anacron/cron.daily
/var/spool/anacron/cron.weekly

If the contents of these files lag more than one period, anacron considers the job overdue. Delete a timestamp to force a job to rerun:

sudo rm /var/spool/anacron/cron.daily
sudo anacron -f -d cron.daily

#System Cron Directories

#/etc/cron.hourly|daily|weekly|monthly/

These system directories run every script inside them at a given interval. To add a job, just drop in an executable script:

sudo cp /usr/local/bin/my-task.sh /etc/cron.daily/
sudo chmod +x /etc/cron.daily/my-task.sh

#run-parts: Executor of Directory Contents

The mechanism behind this is run-parts — a command that runs every executable file in a directory, per naming rules:

sudo run-parts --report /etc/cron.daily

Filenames may only contain letters, digits, dashes, and underscores. A dot (e.g. script.sh) is generally rejected by run-parts in most implementations:

ls -l /etc/cron.daily/ | head

#How Does This Connect to Cron?

The following lines in /etc/crontab connect the two — cron triggers run-parts at given intervals:

25 6    * * *   root  test -x /usr/sbin/anacron && /usr/sbin/anacron
47 6    * * 7   root  test -x /usr/sbin/anacron && /usr/sbin/anacron

In cronie, cron.daily is actually run by anacron whenever the machine is active and overdue — not by precise cron. This is why on many distros, cron.daily jobs can appear at unpredictable times.

#When to Use Which?

#Closing

Key takeaways:

• Anacron runs missed jobs for non-24/7 machines.
• /etc/anacrontab uses period + delay + job-id, not hour fields.
• Timestamps live in /var/spool/anacron/; delete one to force a rerun.
• cron.daily|weekly|monthly run via run-parts — just drop in an executable script.
• In cronie, daily jobs run via anacron, cron.hourly via precise cron.

In episode 9 we enter production patterns: lock, retry, and idempotency — how flock prevents two jobs from overlapping, proper retry strategies, idempotent scripts, and using timeout. This is what separates jobs that "run" from jobs that are "reliable"!