DEV Community

Cover image for cron, anacron, and systemd timer: Guidelines for Choosing Between Three Linux Task Schedulers
tumf
tumf

Posted on • Originally published at blog.tumf.dev

cron, anacron, and systemd timer: Guidelines for Choosing Between Three Linux Task Schedulers

#devops #linux

Originally published on 2026-02-04
Original article (Japanese): cron・anacron・systemd timer: Linuxタスクスケジューラ3種の使い分け基準

"I want to run backups regularly" or "I want to rotate logs at midnight"—there are three methods to automate tasks in Linux: cron, anacron, and systemd timer. However, many people may wonder, "Which one should I use?"

In this article, we will clarify the characteristics of these three schedulers and provide criteria for deciding which one to choose.

Basic Characteristics of the Three Schedulers

First, let's outline the basic features of each.

cron: A Scheduler with Strict Time Specifications

cron is the oldest task scheduler used in UNIX-like operating systems.

Main Features:

  • Strict Time Specification: Executes jobs at specific times, such as "every day at 2 AM" or "every Monday at 9 AM."
  • Minute-Level Precision: The smallest unit is 1 minute.
  • Designed for Continuous Operation: Assumes the system is running 24/7.
  • Simple Configuration: Can be intuitively set up in crontab format.

Configuration Example:

# Backup every day at 2 AM
0 2 * * * /usr/local/bin/backup.sh

# Generate report every Monday at 9 AM
0 9 * * 1 /usr/local/bin/generate-report.sh
Enter fullscreen mode Exit fullscreen mode

Suitable Use Cases:

  • Machines that are always running, such as servers.
  • Jobs that require strict time specifications (e.g., maintenance outside of business hours).
  • Detailed schedules at minute intervals (e.g., monitoring every 5 minutes).

Constraints:

  • Jobs during system downtime will not be executed.
  • The next job can start even if the previous one has not finished (risk of overlapping execution).
  • Checking logs can be cumbersome (need to look in /var/log/syslog or /var/log/cron).

anacron: A Daily Scheduler That Doesn't Miss Jobs When Powered Off

anacron is designed for machines that are not always running.

Main Features:

  • Frequency-Based Execution: Specifies execution based on frequency, such as "once a day" or "once every 7 days."
  • Compensation for Missed Jobs: Automatically executes jobs that have not run during system startup.
  • Minimum Unit is a Day: Minute-level specifications are not possible.
  • Not a Daemon: Typically operates by being called periodically from cron or systemd.

Configuration Example (/etc/anacrontab):

# period  delay  job-id  command
1         5      cron.daily    run-parts /etc/cron.daily
7         10     cron.weekly   run-parts /etc/cron.weekly
@monthly  15     cron.monthly  run-parts /etc/cron.monthly
Enter fullscreen mode Exit fullscreen mode

How It Works:

  1. anacron records the last execution time of jobs in /var/spool/anacron/.
  2. At system startup (or periodically from cron), it checks for missed jobs.
  3. Executes the jobs after the specified delay time.

Suitable Use Cases:

  • Laptops or desktops that have periods of being powered off.
  • Daily, weekly, or monthly maintenance tasks.
  • Jobs that do not require strict time specifications (e.g., backups, package updates).

Constraints:

  • Minute-level detailed scheduling is not possible.
  • Cannot specify strict times (only delay time after startup can be specified).
  • Standard settings often require root operation (when using /etc/anacrontab).

systemd timer: A Modern Integrated Scheduler

systemd timer is a task scheduler provided as part of systemd.

Main Features:

  • Flexible Schedule Specification: Allows for various specifications, including strict times, relative times, and elapsed time after startup.
  • Compensation for Missed Jobs: Can operate similarly to anacron with Persistent=true.
  • Integration with systemd: Unified handling of service management, logging, and dependencies.
  • Random Delay: Can randomize execution times with RandomizedDelaySec.

Configuration Example:

Timer file (backup.timer):

[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=1h

[Install]
WantedBy=timers.target
Enter fullscreen mode Exit fullscreen mode

Service file (backup.service):

[Unit]
Description=Backup service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
Enter fullscreen mode Exit fullscreen mode

Suitable Use Cases:

  • Systems that adopt systemd.
  • Complex scheduling requirements (e.g., executing 24 hours after the last run, or 15 minutes after startup).
  • When there are dependencies between services.
  • When centralized logging is necessary.

Constraints:

  • Not usable on systems that do not use systemd.
  • Requires two configuration files (.timer and .service), resulting in more verbosity compared to cron.
  • Slightly higher learning curve.

Comparison Table of the Three Schedulers

Item cron anacron systemd timer
Minimum Unit 1 minute 1 day Less than a second (default AccuracySec is 1 minute)
Time Specification ✅ Strict ❌ Not possible ✅ Strict
Compensation for Missed Jobs ❌ None ✅ Yes ✅ Yes (Persistent=true)
Prevention of Overlapping Execution ❌ None ✅ Yes ✅ Yes
Log Checking syslog syslog journalctl -u <unit>
General User ✅ Possible △ Possible (-S spooldir) ✅ Possible
Simplicity of Configuration ✅ 1 file ✅ 1 file ❌ 2 files
Dependency Management ❌ None ❌ None ✅ Yes
Random Delay ❌ None △ delay (not random) ✅ Yes (RandomizedDelaySec)

Guidelines for Choosing Between Them

Case 1: Strict Time Specification Needed on a Server

Conclusion: Use cron

  • Maintenance outside of business hours (e.g., every day at 2 AM).
  • Regular report generation (e.g., every Monday at 9 AM).
  • High-frequency monitoring (e.g., every 5 minutes).

Reason:

  • Simple and low learning cost.
  • Allows for strict time specifications.
  • Supports detailed schedules at minute intervals.

Case 2: Daily Backup on a Laptop

Conclusion: Use anacron or systemd timer

  • Daily tasks on machines that have powered-off periods.
  • Maintenance that does not require strict time specifications.

Choose anacron if:

  • You want to keep the configuration simple.
  • You want to leverage existing /etc/cron.daily setups.

Choose systemd timer if:

  • You want centralized logging with journalctl.
  • There are dependencies between services.
  • You want to distribute load with random delays.

Case 3: Complex Scheduling Requirements

Conclusion: Use systemd timer

  • Execute 24 hours after the last run.
  • Execute 15 minutes after system startup.
  • Execute after a specific service has started.

Reason:

  • Supports various triggers like OnBootSec, OnUnitActiveSec.
  • Manages service dependencies with After=, Requires=.

For details on the format of OnCalendar and timer precision (AccuracySec), refer to systemd.time(7) and systemd.timer(5).

Case 4: Improving Existing cron Jobs

Conclusion: Migrate to systemd timer

Benefits of Migration:

  • Logs can be easily checked with journalctl.
  • Prevents overlapping execution if the previous job has not finished.
  • Allows for load distribution with random delays.
  • Manual execution is straightforward (systemctl start service.service).

Example Migration Steps:

  1. Check crontab entries. 
crontab -l
# 0 2 * * * /usr/local/bin/backup.sh
Enter fullscreen mode Exit fullscreen mode
  1. Create systemd timer and service. 
# ~/.config/systemd/user/backup.timer
[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=02:00
Persistent=true

[Install]
WantedBy=timers.target
Enter fullscreen mode Exit fullscreen mode 
# ~/.config/systemd/user/backup.service
[Unit]
Description=Backup service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
Enter fullscreen mode Exit fullscreen mode
  1. Enable the timer. 
systemctl --user daemon-reload
systemctl --user enable --now backup.timer
Enter fullscreen mode Exit fullscreen mode
  1. Confirm operation. 
# Check the list of timers
systemctl --user list-timers

# Check logs
journalctl --user -u backup.service
Enter fullscreen mode Exit fullscreen mode

Practical Example: Automating Backups on a Laptop

Here, we will introduce an example of executing daily backups on a laptop that has powered-off periods.

Using anacron

  1. Create a backup script. 
#!/bin/bash
# /usr/local/bin/backup.sh

BACKUP_DIR="/mnt/backup"
DATE=$(date +%Y%m%d)

rsync -av --delete /home/user/Documents/ "$BACKUP_DIR/$DATE/"
Enter fullscreen mode Exit fullscreen mode
  1. Place it in /etc/cron.daily/. 
sudo cp /usr/local/bin/backup.sh /etc/cron.daily/backup
sudo chmod +x /etc/cron.daily/backup
Enter fullscreen mode Exit fullscreen mode
  1. anacron will execute it automatically.

On Ubuntu/Debian, anacron is set up by default to run /etc/cron.daily/ daily. Even if the machine is powered off, missed jobs will be compensated during the next startup.

Using systemd timer

  1. Create the backup script (same as above).

  2. Create the service file.

# ~/.config/systemd/user/backup.service
[Unit]
Description=Daily backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
Enter fullscreen mode Exit fullscreen mode
  1. Create the timer file. 
# ~/.config/systemd/user/backup.timer
[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=30min

[Install]
WantedBy=timers.target
Enter fullscreen mode Exit fullscreen mode
  1. Enable the timer. 
systemctl --user daemon-reload
systemctl --user enable --now backup.timer
Enter fullscreen mode Exit fullscreen mode
  1. Confirm operation. 
# Check the next execution time
systemctl --user list-timers backup.timer

# Manually execute for testing
systemctl --user start backup.service

# Check logs
journalctl --user -u backup.service
Enter fullscreen mode Exit fullscreen mode

Advantages of systemd timer:

  • Logs can be easily checked with journalctl.
  • Execution times can be randomized with RandomizedDelaySec for load distribution.
  • Persistent=true compensates for missed jobs.
  • Manual execution is straightforward (systemctl start).

Frequently Asked Questions

Q1: Is anacron still in use?

A: Yes, it is installed by default in desktop environments like Ubuntu/Debian and is used to execute /etc/cron.daily and similar tasks. However, there is a trend toward migrating to systemd timer, and new projects are increasingly opting for systemd timer.

Q2: Should I migrate from cron to systemd timer?

A: It is worth considering migration if:

  • You find checking logs cumbersome.
  • The next job starts even if the previous one has not finished.
  • You want to manage dependencies between services.
  • You frequently perform manual executions.

On the other hand, if your jobs are simple and sufficient with cron, there is no need to force a migration.

Q3: Is the learning curve for systemd timer high?

A: Compared to cron, it requires two configuration files, resulting in more verbosity. However, you can easily check the list of timers and logs with the systemctl command, making operational management easier in many cases.

Q4: Can general users use systemd timer?

A: Yes, you can place files in ~/.config/systemd/user/ and manage them with the systemctl --user command. However, to ensure that the timer continues to run after logging out, you need to execute loginctl enable-linger username (loginctl(1)).

Conclusion

It is important to choose the appropriate Linux task scheduler based on your needs.

Guidelines for Selection:

  • Strict time specification on servers: cron
  • Daily tasks on laptops: anacron or systemd timer
  • Complex schedules: systemd timer
  • Improving existing cron jobs: migrate to systemd timer

Personally, I believe that on systems using systemd, new jobs should be created with systemd timer, and existing cron jobs should gradually be migrated. The centralized management of logs and prevention of overlapping execution can significantly reduce operational overhead.

If you're interested, start by trying out systemd timer with a simple job.

Reference Links

Top comments (0)