Welcome to Day 15 of the 30 Days of Linux Challenge!

Today, I explored how Linux automates recurring tasks — saving time, reducing errors, and keeping systems healthy even without manual intervention.

In Red Hat Linux (RHEL, CentOS, Rocky, AlmaLinux), you typically automate with:

  • cron for strict, time-based scheduling
  • anacron for flexible, missed-job recovery
  • systemd timers for a powerful, modern alternative with persistence and event logging

📚 Table of Contents

Why Task Scheduling Matters

Imagine needing to:

  • Run backups at 2 AM daily
  • Clean old logs every Sunday
  • Check disk space and email alerts weekly
  • Pull system updates automatically once a night

Would you want to stay awake for that?

No.

Automation is the answer.

Task scheduling ensures your servers, VMs, and laptops perform critical background tasks consistently — without relying on human memory.

Cron: Classic Time-Based Scheduling

Cron is the oldest and most familiar scheduler.

Each user has their own crontab (cron table) which defines tasks to run at specific times.

View your current crontab:

crontab -l

Image description

Edit your crontab:

crontab -e

Cron job syntax:

  • * * * * /path/to/command # | | | | | # | | | | └── Day of the week (0-6, Sunday=0) # | | | └──── Month (1-12) # | | └────── Day of month (1-31) # | └──────── Hour (0-23) # └────────── Minute (0-59)

Example:
Run a backup every day at 2:30 AM:

30 2 * * * /home/youruser/scripts/backup.sh

Anacron: Handling Unreliable Uptime

Anacron is designed for systems that might not be running 24/7 — like laptops or occasionally powered-off servers.

Instead of running at a strict time, it ensures a job runs after boot if the scheduled time was missed.

Image description

Anacron config:

/etc/anacrontab

Anacron entry format:
period delay job-identifier command

Field Meaning
period :: Days between runs (1 = daily)
delay :: Minutes to wait after boot
job-identifier :: Unique name for the job
command :: Command to execute

Example:
Run /backup.sh every day, wait 10 minutes after boot:

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

Systemd Timers: The Modern Alternative

If your server uses systemd (almost all Red Hat-based systems now do), systemd timers offer:

  • Tight integration with system services
  • Persistent behavior (they catch up if missed)
  • Better logging via journalctl
  • Flexibility (timers can be linked to events, not just clock times)

Systemd timer setup:

Create a service file /etc/systemd/system/backup.service:

[Unit]
Description=Backup Script

[Service]
ExecStart=/home/youruser/scripts/backup.sh
Create a timer file /etc/systemd/system/backup.timer:

[Unit]
Description=Runs backup script daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target
Reload systemd and start the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
sudo systemctl list-timers

Persistent=true ensures the job still runs if the server missed the scheduled time (e.g., due to downtime).

Common Real-World Use Cases

Task Tool Notes
Daily backups at 2 AM Cron If server uptime is reliable
Weekly security scans Systemd Timer Better control and logging
Cleanup scripts after boot Anacron If uptime is unpredictable
Monitor system disk space Cron + Email Lightweight solution

Try It Yourself

Check your crontab
crontab -l

Add a new scheduled job
crontab -e

(e.g., 0 3 * * * /home/youruser/scripts/daily_report.sh)

Explore anacron
cat /etc/anacrontab

Check systemd timers
sudo systemctl list-timers

Create your first backup.timer + backup.service
(start small, e.g., backup /home/youruser/ once a day)

Why This Matters

  • Knowing how to schedule tasks helps you:
  • Automate server maintenance
  • Create reliable backup strategies
  • Reduce manual errors
  • Ensure business continuity without constant monitoring

In any professional sysadmin, DevOps, or cloud engineering role, reliable automation is a critical expectation — not a bonus skill.