Learning Cron Job - Core Concepts & Main Architecture

#Introduction

In episode 1 we understood the history and the reasons cron exists. Now we dissect its mechanics: how a single small daemon named crond can trigger dozens of commands on time every day, without ever forgetting and without human intervention.

Understanding this architecture matters before writing crontab, because many classic errors — jobs that don't run, jobs that run twice, or jobs that run at unexpected times — have their roots in how crond reads and interprets schedule files. Let's pop the hood.

#Main Architecture

#crond: The Daemon That Never Sleeps

crond is a daemon — a process that runs in the background at all times. Every minute, it wakes up, reads all schedule files (crontabs), compares the current time with the time fields on each line, then runs the commands that match.

systemctl status crond
pgrep -x crond

Its workflow:

1. crond reads per-user crontabs and system files.
2. Every minute, it checks the minute hour day month weekday fields.
3. If all fields match the current time, it runs the command through a shell.
4. Command output is captured to be emailed or discarded (episode 5).

#Time Fields: Cron's Scheduling Language

Each crontab line has 5 time fields in front of the command:

minute hour day-of-month month day-of-week  command

• minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), day-of-week (0-7, where 0 and 7 are both Sunday).
• Each field can contain * (all values), lists, ranges, or steps.

We'll break down the full syntax and all special characters in detail in episode 3.

#Cron Components

Cron's architecture consists of several files and directories that complement each other:

#crond and the crontab command

Two different binaries:

• crond — the daemon that executes schedules.
• crontab — the program that manages per-user schedule files (episode 4).

which crond
which crontab

#/etc/crontab: System Crontab

The system-level schedule file. The difference from a per-user crontab: schedule lines here have a user field that determines who runs the command.

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
 
25 6    * * *   root  test -x /usr/sbin/anacron && /usr/sbin/anacron

#/etc/cron.d/: Crontab Snippets

A directory containing additional schedule files in the same format as /etc/crontab (including the user field). It's used by packages like logrotate to register their own schedules without touching /etc/crontab.

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

Special directories that run every script inside them at a given interval, via run-parts. Just drop an executable script into /etc/cron.daily/ and it automatically runs every day. We'll cover the details in episode 8.

ls -l /etc/cron.daily/

#anacron: A Safety Net for Machines Not Always On

As in episode 1, anacron catches up on missed jobs. In cronie, it runs from /etc/cron.daily/ and reads the /etc/anacrontab configuration. If the machine was asleep at the scheduled time, the job runs as soon as the machine is active again.

#Execution Flow Map

For clarity, here's the full flow as a minute rolls over:

1. crond wakes up and scans all crontabs (per-user in /var/spool/cron/, /etc/crontab, /etc/cron.d/).
2. For each line, it matches the time fields against the current time.
3. Matching lines are executed as the relevant user, through the shell per SHELL.
4. The cron.daily and friends directories are run via run-parts on their schedule.
5. Output and errors are collected to be sent to MAILTO or discarded.

#Component Comparison

#Closing

Key takeaways:

• crond is the daemon that wakes up every minute and matches time fields.
• The five time fields: minute hour day-of-month month day-of-week + command.
• Per-user crontabs live in the spool; system crontabs in /etc/crontab and /etc/cron.d/.
• The cron.hourly|daily|weekly|monthly directories run via run-parts.
• anacron handles jobs missed while the machine was off.

In episode 3 we'll fully dissect crontab syntax and time fields — the *, ,, -, and / characters, month and day names, plus the OR/AND rules that frequently trap beginners. After this episode, you'll be able to read and write any cron schedule with confidence!