Cron Scheduling — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about cron and job scheduling.
Cron is older than most operating systems in use today¶
Cron was created by Ken Thompson for Version 7 Unix in 1979 — the same year the Sony Walkman was released. The modern vixie-cron, written by Paul Vixie in 1987, is the ancestor of virtually every cron implementation on Linux today. Vixie was 24 years old when he wrote it.
The name "cron" comes from Chronos¶
Cron is short for "chronos," the Greek word for time (and the name of the Greek god of time). Despite this classical origin, cron's five-field syntax (minute hour day month weekday) was a purely pragmatic engineering decision by Thompson, not inspired by any timekeeping tradition.
The crontab format has an ambiguity that has never been resolved¶
When both "day of month" and "day of week" are specified, cron runs the job when EITHER matches, not when both match. This OR-logic (not AND-logic) surprises nearly every new cron user and has been called "the most counterintuitive design decision in Unix." It dates back to the original 1979 implementation and cannot be changed without breaking millions of crontabs.
@reboot runs at daemon start, not system boot¶
The @reboot shorthand does not actually detect a system reboot. It fires whenever the cron daemon starts. If you restart crond manually, all @reboot jobs will run again. This subtle distinction has caused production incidents when administrators restarted cron to pick up configuration changes.
Cron has no built-in overlap protection¶
If a cron job takes longer than the interval between runs, cron will happily launch another instance in parallel. This has caused countless cascading failures in production. The standard workaround — using flock for file-based locking — was not available until the util-linux package added it in 2004, leaving 25 years of cron without a clean solution.
The percent sign is a hidden feature and a hidden trap¶
In a crontab entry, the % character is interpreted as a newline, and everything after the first % is fed to the command as standard input. This means date +%Y-%m-%d in a crontab will break unless you escape it as date +\%Y-\%m-\%d. This quirk has been the #1 most-asked cron question on Stack Overflow.
Vixie cron added per-user crontabs¶
The original Version 7 cron only had a single system-wide crontab file editable by root. Paul Vixie's 1987 rewrite introduced per-user crontabs via the crontab -e command, democratizing scheduled tasks. This was considered radical at the time — giving unprivileged users the ability to schedule recurring processes.
Systemd timers are cron's first real competitor in 40 years¶
Systemd timers, introduced around 2012, are the first widely-adopted alternative to cron on Linux. They offer monotonic timers (relative to boot), calendar expressions, built-in logging via journald, and dependency ordering. Despite these advantages, cron remains more widely used due to its simplicity and the inertia of billions of existing crontab entries.
Cron's minimum resolution is one minute — by design¶
Cron checks its tables once per minute and cannot schedule jobs at sub-minute intervals. This was a deliberate design choice in 1979 when CPU cycles were precious. For sub-minute scheduling, the common hack is * * * * * sleep 30 && command to run every 30 seconds, which feels deeply wrong but works.
The cron environment is deliberately minimal¶
Cron jobs run with a stripped-down environment — typically just HOME, LOGNAME, SHELL=/bin/sh, and a minimal PATH (often /usr/bin:/bin). This is the #2 cause of "works on my terminal but not in cron" bugs, after the percent-sign issue. The fix is to set variables at the top of your crontab or source your profile.
Anacron was invented for laptops¶
Anacron (1998) was created because cron assumes the machine is always on. If a laptop is off at 3 AM, the nightly job simply never runs. Anacron tracks the last run date in /var/spool/anacron/ and catches up on missed jobs when the machine wakes. Modern systemd timers adopted this concept with Persistent=true.
The "0 0 30 2 *" crontab entry is valid but never fires¶
You can write a crontab entry for February 30th and cron will accept it without complaint. It will simply never execute. This has been used as a joke "disabled" job and as an interview question to test cron knowledge.