Cron and System Timers

Scripting and Automation: Cron and System Timers

Introduction to Job Scheduling

In the Linux ecosystem, system administrators rarely execute maintenance tasks manually. Tasks such as log rotation, database backups, and temporary file cleanup must occur reliably at specific intervals, day or night. This automation is achieved primarily through two mechanisms: the traditional Cron daemon and the modern Systemd Timers. Understanding these tools is essential for the CompTIA Linux+ certification, as they represent the backbone of system automation.

What is Cron?

Cron is a time-based job scheduler that runs in the background as a daemon (crond). It wakes up every minute to check configuration files (known as crontabs) to see if any commands are scheduled to run at that current minute. It is vital for recurring tasks that occur at specific times (e.g., 'Every Monday at 3:00 AM').

How Cron Works

Cron configuration is handled in two primary ways: User Crontabs and System Crontabs.

1. The Crontab Syntax
To master Cron for the exam, you must memorize the five fields that precede the command. The order is strict:
Minute Hour DayOfMonth Month DayOfWeek

values:
Minute: 0-59
Hour: 0-23
Day of Month: 1-31
Month: 1-12 (or JAN-DEC)
Day of Week: 0-7 (0 and 7 are both Sunday, or SUN-SAT)

Special Characters:
*: Any value (do it every time unit).
,: List separator (e.g., 1,15 means run on the 1st and 15th).
-: Range (e.g., 1-5 means run on 1 through 5).
/: Step values (e.g., */5 in the minute field means every 5 minutes).

2. Configuration Files
User Crontabs: Edited using the command crontab -e. Files are stored in /var/spool/cron/.
System Crontab: Located at /etc/crontab. Since this implies the root user, it includes an extra field specifying the User to run the command as, inserted between the time fields and the command.
Cron Directories: Linux simplifies scheduling scripts by providing directories like /etc/cron.daily, /etc/cron.weekly, and /etc/cron.hourly. Any executable script placed inside these directories runs automatically at the system's pre-configured interval.
Access Control: Use /etc/cron.allow and /etc/cron.deny to control which users can create cron jobs.

What are Systemd Timers?

Systemd Timers are the modern alternative to Cron, preferred in newer distributions using systemd init systems. They offer advantages such as better logging, dependency management (a job can depend on network availability), and jitter (randomized delays).

How Systemd Timers Work

Unlike Cron, which uses a single line of text, Systemd Timers essentially use two files:
1. The Service Unit (.service): Defines what to do (the script or command to run).
2. The Timer Unit (.timer): Defines when to do it.

Types of Timers:
Monotonic: Triggers relative to an event (e.g., OnBootSec=15min runs 15 minutes after boot).
Realtime: Triggers on wall-clock time, similar to Cron (e.g., OnCalendar=Mon *-*-* 10:00:00).

Management Commands:
To view active timers: systemctl list-timers.
To enable a timer: systemctl enable --now example.timer.

Exam Tips: Answering Questions on Cron and System Timers

When facing scheduling questions on the CompTIA Linux+ exam, apply these strategies:

1. Count the Fields: If you see a cron syntax question, immediately identify if there are 5 time fields or 6. If there are 5, it is a user crontab. If there are 6 (the 6th being a username like 'root'), it is the system-wide /etc/crontab.

2. Verify 'Day of Week': Remember that 0 and 7 both represent Sunday. If a question asks for a job to run on a weekend, look for 0, 6, 7, SAT, or SUN.

3. Distinguish Anacron: If a question mentions a laptop or workstation that is frequently powered off, the answer isn't standard Cron; it is likely Anacron. Anacron (configured via /etc/anacrontab) ensures that daily/weekly jobs missed while the computer was off are run immediately upon booting.

4. Systemd Syntax: Look for the keyword OnCalendar. If you are asked to configure a systemd timer to run every Monday, you need to modify the .timer file, not the .service file.

5. Troubleshooting: If a user cannot edit their cron jobs, the answer usually involves permissions in /etc/cron.deny or /etc/cron.allow. If a script in /etc/cron.daily isn't running, check if the file has execute permissions (chmod +x).