Back to Blog
Tutorial

Anacron vs. Cron: Scheduling Tasks on Machines That Aren't Always On

Your laptop is off when cron jobs should run? Anacron solves this problem by running missed jobs when your machine boots up. Learn when to use anacron vs. cron for desktop and laptop scheduling.

•
10 min read
•By Cron Generator Team
Share:TwitterLinkedIn

Your laptop sits in your bag all weekend. Monday morning, you open it expecting your automated backup to have run on Sunday at 2 AM.

It didn't run. Because your laptop was off.

Cron schedules tasks for specific times. If your machine is off at that time, the job is simply skipped. Forever. It won't run when you power on. It just... disappears into the void of missed opportunities.

This is where anacron comes in.

Anacron is specifically designed for machines that aren't running 24/7—desktops, laptops, workstations. It ensures important periodic tasks actually run, even if your machine was off when they were scheduled.

This guide explains exactly when you need anacron instead of cron, how it works differently, and how to use it effectively.

The Problem with Cron on Desktops and Laptops

How Cron Works (And Why It Fails on Laptops)

Cron is time-based scheduling. It wakes up every minute and asks: "Is it time to run any jobs?"

Example cron job:

0 2 * * * /home/user/backup.sh

What cron does:

  • At 2:00 AM, check if backup.sh should run
  • If yes, execute it
  • If the machine is off, do nothing
  • Move on to the next minute

The critical flaw for laptops: If your laptop is sleeping, hibernating, or powered off at 2:00 AM, cron simply skips the job.

Real-World Laptop Scenarios

Scenario 1: Weekend Away

You configure a weekly backup for Sunday at 2 AM:

0 2 * * 0 /home/user/weekly-backup.sh

What happens:

  • Friday evening: Close laptop, go home for weekend
  • Sunday 2 AM: Laptop is in your bag, powered off
  • Cron: "Time to run backup... oh, system is off. Skip."
  • Monday morning: Open laptop, no backup was created

Your weekly backup never ran.

Scenario 2: Daily Tasks That Need to Happen

You want to clear cache daily at 3 AM:

0 3 * * * rm -rf ~/.cache/temp/*

What happens:

  • You shut down your laptop at midnight
  • You start it at 8 AM the next day
  • The 3 AM window was missed entirely
  • Cache is never cleared

Day after day, the job doesn't run if you're not keeping your laptop on 24/7.

Scenario 3: The "I'll Keep It On Tonight" Promise

You think: "I'll just leave my laptop on tonight so the backup runs."

Reality:

  • You forget to disable sleep mode
  • Laptop goes to sleep at 3:15 AM
  • Backup was scheduled for 3:30 AM
  • Job doesn't run anyway

You can't rely on human behavior for critical tasks.

Why This Matters

Tasks that should run regularly, regardless of uptime:

  • ✅ Backups (daily, weekly)
  • ✅ System updates
  • ✅ Virus scans
  • ✅ Database vacuum/optimization
  • ✅ Photo/file synchronization
  • ✅ Log cleanup
  • ✅ Package cache cleanup

These need to run eventually, even if not at the exact scheduled time.

The Desktop/Laptop Reality

Typical laptop usage patterns:

  • Closed during commute
  • Sleeping during lunch
  • Powered off overnight
  • Hibernating on weekends
  • Uptime: 8-10 hours per day, irregular schedule

Cron expects: 24/7 uptime

Result: Massive job execution gaps

Anacron to the Rescue

What Anacron Does Differently

Anacron is interval-based scheduling with catch-up capability.

Core difference:

| Cron | Anacron | |------|---------| | "Run at 2:00 AM" | "Run once per day" | | Exact time | Approximate interval | | Skips missed jobs | Runs missed jobs when system boots | | Time-sensitive | Interval-sensitive |

How anacron thinks:

Instead of "Is it 2 AM?", anacron asks:

  1. "When did this job last run?"
  2. "Has enough time passed since then?"
  3. "If yes, run it now (even if it's 3 PM)"

The Catch-Up Mechanism

Example: You configure a daily backup.

Monday:

  • Laptop boots at 9 AM
  • Anacron: "Last backup was Sunday evening. More than 1 day ago."
  • Anacron: "Running backup now at 9:05 AM"
  • Backup completes successfully

Tuesday:

  • Laptop boots at 8 AM
  • Anacron: "Last backup was Monday at 9:05 AM. Not yet 24 hours."
  • Anacron: "Skip for now, check again later"

Later Tuesday:

  • Still running at 11 AM
  • Anacron: "Last backup was Monday 9:05 AM. Now 26 hours ago."
  • Anacron: "Running backup now at 11 AM"

The job runs approximately daily, whenever the machine is on.

Anacron's Design Philosophy

Built for intermittent machines:

  • Doesn't care about exact time
  • Cares about intervals (daily, weekly, monthly)
  • Runs jobs shortly after boot if they're overdue
  • Updates timestamps to track last execution
  • Prevents duplicate runs on the same day

Perfect for:

  • Desktop workstations
  • Laptops
  • Personal computers
  • Any machine with irregular uptime

Not for:

  • Production servers (use cron)
  • Time-sensitive operations (use cron)
  • Sub-daily precision (use cron)

How Anacron Works

The Anacrontab File

Unlike cron's /etc/crontab or user crontabs, anacron uses /etc/anacrontab:

# /etc/anacrontab

# period  delay  job-identifier  command

1         5      daily-backup    /home/user/scripts/backup.sh
7         10     weekly-scan     /home/user/scripts/virus-scan.sh
30        15     monthly-update  /home/user/scripts/update-packages.sh

Field breakdown:

| Field | Meaning | Example | |-------|---------|---------| | period | Days between runs | 1 = daily, 7 = weekly, 30 = monthly | | delay | Minutes to wait after boot | 5 = wait 5 minutes before running | | job-identifier | Unique name for job | daily-backup (no spaces) | | command | What to execute | /path/to/script.sh |

Understanding the Period Field

Period is in days:

1    # Run once per day
3    # Run once every 3 days
7    # Run once per week
15   # Run once every 15 days
30   # Run once per month (approximately)

Anacron tracks: "How many days since this job last ran?"

If period has passed: Job runs on next opportunity (boot or anacron check).

The Delay Field: Why Wait?

Why delay after boot?

System is busy immediately after boot:

  • Services starting up
  • Network connecting
  • User logging in
  • Applications loading

Running heavy jobs immediately can slow down boot.

Delay provides breathing room:

# Bad: All jobs start immediately
1  0  backup   /scripts/backup.sh
7  0  scan     /scripts/scan.sh

# Good: Staggered starts
1  5   backup   /scripts/backup.sh  # Waits 5 minutes
7  10  scan     /scripts/scan.sh    # Waits 10 minutes

Typical delays:

  • 5-15 minutes for light jobs
  • 15-30 minutes for heavy jobs (backups, scans)

Job Identifier: Timestamp Tracking

Job identifier is critical. Anacron uses it to track execution.

Timestamp files stored in: /var/spool/anacron/

ls /var/spool/anacron/
daily-backup
weekly-scan
monthly-update

Each file contains: Date of last execution

cat /var/spool/anacron/daily-backup
20250109

This is how anacron knows if the job needs to run again.

Important: Use unique, descriptive identifiers:

# Good identifiers
daily-backup
weekly-virus-scan
monthly-package-update

# Bad identifiers (confusing)
job1
backup
task

How Anacron Runs

Two ways anacron executes:

1. At boot (via systemd or init)

Most systems run anacron shortly after boot:

# Check if anacron is enabled
systemctl status anacron

On boot:

  • Anacron daemon starts
  • Reads /etc/anacrontab
  • Checks each job's timestamp
  • Runs overdue jobs with specified delays

2. Periodic checks (on some systems)

Some distributions run anacron daily via cron:

# In /etc/cron.daily/
/etc/cron.daily/0anacron

This creates a hybrid: Cron triggers anacron daily, anacron handles catch-up.

Example Execution Flow

You have:

# /etc/anacrontab
1  10  daily-backup  /home/user/backup.sh

Timeline:

Monday 9:00 AM: Boot laptop

  • 9:00 AM: System starts, anacron starts
  • 9:10 AM: Anacron checks daily-backup
  • Last run: Sunday 3:00 PM (more than 1 day ago)
  • 9:10 AM: Anacron runs backup.sh
  • 9:15 AM: Backup completes, timestamp updated to Monday

Tuesday 8:00 AM: Boot laptop

  • 8:00 AM: System starts, anacron starts
  • 8:10 AM: Anacron checks daily-backup
  • Last run: Monday 9:10 AM (less than 24 hours)
  • Decision: Skip (not yet 1 full day)

Tuesday 5:00 PM: Still running

  • Anacron checks again (some systems do periodic checks)
  • Last run: Monday 9:10 AM (now 32 hours ago, over 1 day)
  • Decision: Run now
  • 5:00 PM: Backup runs, timestamp updated to Tuesday

Wednesday: Laptop not turned on

  • No boot = no anacron = no jobs run
  • Timestamp still shows Tuesday 5:00 PM

Thursday 7:00 AM: Boot laptop

  • 7:00 AM: System starts, anacron starts
  • 7:10 AM: Anacron checks daily-backup
  • Last run: Tuesday 5:00 PM (over 1 day ago)
  • 7:10 AM: Catches up, runs backup
  • Timestamp updated to Thursday

The job runs approximately daily, regardless of irregular schedule.

Anacron vs. Cron: When to Use Which

Clear Decision Matrix

| Your Situation | Use This | Why | |----------------|----------|-----| | Server (24/7 uptime) | Cron | Precise timing, server always on | | Laptop/Desktop | Anacron | Handles irregular uptime | | Task must run at exact time | Cron | Anacron doesn't guarantee exact time | | Task must run regularly | Anacron | Ensures it runs eventually | | Multiple times per day | Cron | Anacron is days-only | | Daily/weekly/monthly tasks | Anacron | Perfect for interval-based | | Time-sensitive (reports, alerts) | Cron | Specific time required | | Maintenance (backups, updates) | Anacron | Time doesn't matter, completion does | | Workstation with irregular hours | Anacron | Handles machine being off | | Database server | Cron | Predictable, precise scheduling |

Use Cron When:

✅ Machine is always on

  • Production servers
  • Cloud instances
  • Always-running services

✅ Exact timing matters

  • Business reports (must run at 9 AM sharp)
  • Real-time alerts
  • Time-synchronized operations

✅ High frequency needed

  • Every 15 minutes
  • Every hour
  • Multiple times per day

✅ Sub-daily precision

  • Specific hours and minutes
  • Complex schedules (weekdays at 9 AM and 5 PM)

Example cron jobs:

# Generate morning report at 9 AM sharp
0 9 * * 1-5 /usr/local/bin/generate-report.sh

# Check API health every 5 minutes
*/5 * * * * /usr/local/bin/health-check.sh

# Backup database at exactly 2 AM (low-traffic time)
0 2 * * * /usr/local/bin/backup-database.sh

Use Anacron When:

✅ Machine has irregular uptime

  • Laptops
  • Desktops
  • Workstations

✅ Task should run periodically

  • Daily maintenance
  • Weekly scans
  • Monthly cleanup

✅ Exact time doesn't matter

  • Backups (anytime is fine)
  • Cache clearing
  • Package updates
  • File synchronization

✅ Catch-up is important

  • Must run even if laptop was off
  • Can't skip weeks of backups
  • Need eventual execution

Example anacron jobs:

# Daily backup (whenever machine is on)
1  10  daily-backup  /home/user/scripts/backup.sh

# Weekly virus scan
7  15  weekly-scan   /home/user/scripts/virus-scan.sh

# Monthly system cleanup
30 20  monthly-clean /home/user/scripts/cleanup.sh

Hybrid Approach: Use Both

Many systems use both:

Cron for:

  • Frequent checks (every 15 minutes)
  • Time-sensitive operations
  • System services

Anacron for:

  • Daily maintenance
  • Weekly tasks
  • Monthly operations

Example combination:

# Cron (/etc/crontab)
*/15 * * * * root /usr/local/bin/quick-check.sh
0 9 * * 1-5 user /usr/local/bin/morning-report.sh

# Anacron (/etc/anacrontab)
1  10  daily-backup     /home/user/backup.sh
7  15  weekly-update    /home/user/update-system.sh
30 20  monthly-cleanup  /home/user/cleanup.sh

Best of both worlds.

Setting Up Anacron

Installation

Most Linux distributions include anacron by default.

Check if installed:

which anacron
# Output: /usr/sbin/anacron

anacron -V
# Output: Anacron 2.3

If not installed:

Ubuntu/Debian:

sudo apt update
sudo apt install anacron

Fedora/RHEL/CentOS:

sudo dnf install cronie-anacron

Arch Linux:

sudo pacman -S cronie

Configuring Anacron

Edit the anacrontab file:

sudo nano /etc/anacrontab

Basic structure:

# /etc/anacrontab: configuration file for anacron

# Environment variables
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=user@example.com

# period  delay  job-identifier  command

# Run daily jobs with 5-minute delay
1         5      daily-backup    /home/user/scripts/backup.sh

# Run weekly jobs with 10-minute delay
7         10     weekly-scan     /usr/local/bin/virus-scan.sh

# Run monthly jobs with 15-minute delay
30        15     monthly-update  /usr/local/bin/update-packages.sh

Creating Your First Anacron Job

Step 1: Create the script

#!/bin/bash
# File: /home/user/scripts/daily-backup.sh

BACKUP_DIR="/home/user/backups"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Create backup
tar -czf "$BACKUP_DIR/backup_$TIMESTAMP.tar.gz" /home/user/Documents

# Keep only last 7 backups
cd "$BACKUP_DIR"
ls -t backup_*.tar.gz | tail -n +8 | xargs -r rm

echo "Backup completed at $(date)"

Make executable:

chmod +x /home/user/scripts/daily-backup.sh

Step 2: Add to anacrontab

sudo nano /etc/anacrontab

Add line:

1  10  daily-backup  /home/user/scripts/daily-backup.sh

This means:

  • Run once per day (period: 1)
  • Wait 10 minutes after boot (delay: 10)
  • Job name: daily-backup
  • Command: /home/user/scripts/daily-backup.sh

Step 3: Test manually

# Force run all anacron jobs now
sudo anacron -f

# Or test specific job
sudo anacron -f -n daily-backup

Check logs:

# View anacron activity
sudo cat /var/log/syslog | grep anacron

# Or journalctl on systemd systems
sudo journalctl -u anacron

User-Level Anacron

System anacron requires root and runs in /etc/anacrontab.

For user-level jobs, some distributions support user anacrontab, but it's not standard.

Workaround: Systemd user timers (see our Cron vs. Systemd Timers guide) or:

Use cron with anacron-like behavior:

# In user crontab
@reboot sleep 300 && /home/user/scripts/check-and-run-backup.sh

Script checks last run time:

#!/bin/bash
LAST_RUN_FILE="/home/user/.last-backup"
CURRENT_TIME=$(date +%s)

if [ -f "$LAST_RUN_FILE" ]; then
    LAST_RUN=$(cat "$LAST_RUN_FILE")
    TIME_DIFF=$((CURRENT_TIME - LAST_RUN))
    
    # If less than 24 hours (86400 seconds), skip
    if [ $TIME_DIFF -lt 86400 ]; then
        echo "Backup already ran recently, skipping"
        exit 0
    fi
fi

# Run backup
/home/user/scripts/backup.sh

# Update timestamp
echo "$CURRENT_TIME" > "$LAST_RUN_FILE"

This simulates anacron behavior with cron's @reboot.

Common Anacron Patterns

Daily Backup

# /etc/anacrontab
1  10  daily-backup  /usr/local/bin/backup.sh

Runs: Once per day, 10 minutes after boot

Weekly System Update

# /etc/anacrontab
7  15  weekly-update  /usr/local/bin/update-system.sh

Runs: Once per week, 15 minutes after boot

Monthly Cleanup

# /etc/anacrontab
30  20  monthly-cleanup  /usr/local/bin/cleanup.sh

Runs: Once per month, 20 minutes after boot

Staggered Jobs (Prevent Overlap)

# /etc/anacrontab
1   5   backup      /usr/local/bin/backup.sh        # 5 min delay
1   15  sync        /usr/local/bin/sync-files.sh    # 15 min delay
1   25  cleanup     /usr/local/bin/cleanup.sh       # 25 min delay

All run daily, but at different times after boot.

Long-Running Tasks

# /etc/anacrontab
7  30  deep-scan  /usr/local/bin/full-disk-scan.sh

30-minute delay ensures system is fully booted and stable before starting intensive scan.

Troubleshooting Anacron

Check Anacron Status

# Is anacron enabled?
systemctl status anacron

# Is anacron running?
ps aux | grep anacron

View Anacron Logs

Syslog-based systems:

sudo tail -f /var/log/syslog | grep anacron

Systemd-based systems:

sudo journalctl -u anacron -f

Check Timestamp Files

See when jobs last ran:

ls -la /var/spool/anacron/

View specific job timestamp:

cat /var/spool/anacron/daily-backup
20250109

Format: YYYYMMDD (year, month, day)

Manually Trigger Jobs

Force run all overdue jobs:

sudo anacron -f

Force run specific job:

sudo anacron -f -n daily-backup

Test without actually running:

sudo anacron -d -n

Common Issues

Issue 1: Job never runs

Check:

  1. Is anacron installed and enabled?
  2. Is job correctly formatted in /etc/anacrontab?
  3. Does script have execute permissions?
  4. Check logs for errors

Issue 2: Job runs multiple times

Cause: Multiple anacron triggers (boot + cron.daily)

Solution: Check for duplicate anacron invocations:

cat /etc/cron.daily/0anacron

Issue 3: Timestamp not updating

Cause: Job failing silently, anacron doesn't update timestamp

Solution: Add logging to your script, check for errors

Issue 4: Delays not working

Verify delay syntax:

# Correct
1  10  backup  /path/to/script.sh

# Wrong (delay must be number)
1  10m backup  /path/to/script.sh

Anacron Limitations

1. Granularity: Days Only

Anacron measures periods in days, not hours or minutes.

You cannot do:

  • Every 6 hours
  • Twice per day
  • Every 30 minutes

For sub-daily tasks, use cron.

2. No Exact Time Control

Anacron runs "sometime after boot" plus delay.

You cannot specify:

  • Run at 2 AM
  • Run during low-usage hours
  • Run at specific time of day

3. Requires Boot to Trigger

If laptop stays on for weeks, anacron might not check jobs (depends on configuration).

Some systems run anacron daily via cron to mitigate this:

# /etc/cron.daily/0anacron ensures daily anacron checks

But if system never boots AND cron.daily doesn't exist, jobs may not run.

4. Not User-Friendly for Complex Schedules

Anacron is simple by design:

  • Daily, weekly, monthly
  • That's it

For complex schedules (first Monday of month, weekdays only, etc.), use cron or systemd timers.

5. Requires Root for System-Level

System anacron (/etc/anacrontab) requires root access.

User-level anacron is not standardized across distributions.

Real-World Use Cases

Use Case 1: Laptop Backup

Scenario: Personal laptop, irregular usage

Goal: Daily backup to external drive

Solution:

# /etc/anacrontab
1  10  laptop-backup  /home/user/scripts/backup-to-external.sh

Script:

#!/bin/bash
# Check if external drive is mounted
if mountpoint -q /media/backup; then
    rsync -avz /home/user/Documents/ /media/backup/laptop-backup/
    echo "Backup completed at $(date)" >> /var/log/laptop-backup.log
else
    echo "External drive not mounted, skipping backup" >> /var/log/laptop-backup.log
fi

Result: Backup runs daily when laptop is on AND external drive is connected.

Use Case 2: Desktop Maintenance

Scenario: Desktop workstation, turned off nights and weekends

Goal: Weekly system updates and cleanup

Solution:

# /etc/anacrontab
7  15  weekly-maintenance  /usr/local/bin/desktop-maintenance.sh

Script:

#!/bin/bash
# Update packages
apt update && apt upgrade -y

# Clear package cache
apt clean

# Remove old kernels
apt autoremove -y

# Clean temporary files
rm -rf /tmp/*

echo "Maintenance completed at $(date)"

Result: Runs weekly whenever desktop is on, catches up if turned off multiple weeks.

Use Case 3: Developer Workstation

Scenario: Development laptop, inconsistent power schedule

Goal: Sync git repositories daily

Solution:

# /etc/anacrontab
1  20  daily-git-sync  /home/dev/scripts/sync-repos.sh

Script:

#!/bin/bash
REPOS=(
    "/home/dev/projects/webapp"
    "/home/dev/projects/api"
    "/home/dev/projects/mobile"
)

for repo in "${REPOS[@]}"; do
    if [ -d "$repo" ]; then
        cd "$repo"
        git fetch --all
        echo "Synced $repo at $(date)"
    fi
done

Result: All repos stay updated, even with irregular laptop usage.

Anacron Best Practices

1. Use descriptive job identifiers

# Good
1  10  daily-home-backup  /scripts/backup.sh

# Bad
1  10  job1  /scripts/backup.sh

2. Stagger delays to prevent resource contention

1  5   backup   /scripts/backup.sh
1  15  sync     /scripts/sync.sh
1  25  cleanup  /scripts/cleanup.sh

3. Add logging to your scripts

#!/bin/bash
LOG="/var/log/my-anacron-job.log"
echo "[$(date)] Job started" >> "$LOG"
# ... job logic ...
echo "[$(date)] Job completed" >> "$LOG"

4. Make scripts idempotent

Safe to run multiple times without harm:

# Check if already running
LOCKFILE="/var/run/backup.lock"
if [ -f "$LOCKFILE" ]; then
    echo "Backup already running"
    exit 0
fi

touch "$LOCKFILE"
# ... run backup ...
rm "$LOCKFILE"

5. Handle dependencies gracefully

# Check if external drive is mounted before backing up
if ! mountpoint -q /media/backup; then
    echo "Backup drive not available, skipping"
    exit 0
fi

Conclusion: The Right Tool for the Right Job

Cron and anacron solve different problems:

Cron: "Run this command at this exact time"

  • Perfect for servers
  • Precise scheduling
  • Assumes 24/7 uptime

Anacron: "Run this command once per [interval], whenever the machine is on"

  • Perfect for desktops/laptops
  • Interval-based
  • Handles irregular uptime

Most desktop/laptop users don't realize they need anacron. They set up cron jobs and wonder why they never run.

If you're on a laptop or desktop, and you want daily/weekly/monthly tasks to actually run, use anacron.

Your checklist:

✅ Use anacron if:

  • Laptop or desktop workstation
  • Machine isn't on 24/7
  • Task should run periodically (daily, weekly, monthly)
  • Exact timing doesn't matter
  • Catch-up is important

✅ Use cron if:

  • Server with 24/7 uptime
  • Exact time matters
  • High frequency needed (hourly, every 15 minutes)
  • Time-sensitive operations

✅ Use both if:

  • Some tasks need precise timing (cron)
  • Some tasks need catch-up (anacron)

Don't let important tasks go unexecuted just because your laptop was off. Use anacron, and sleep soundly knowing your backups will run eventually.

Ready to schedule tasks that actually run? Use our Cron Expression Generator for server schedules, and anacron for your desktop tasks.

Keywords: anacron vs cron, what is anacron, cron for desktop, linux laptop cron job, anacron tutorial, anacron vs cron linux, missed cron jobs, laptop scheduled tasks, anacron examples, desktop automation linux