Scheduling jobs to run unattended

The five fields

A crontab line is minute, hour, day of month, month, day of week, then the command. Minutes run 0 to 59, hours 0 to 23, day of month 1 to 31, month 1 to 12, and day of week 0 to 7 with both 0 and 7 meaning Sunday. An asterisk means every value, a comma lists them, a hyphen gives a range, and */5 in the minute field means every five minutes.

The rule that catches people: if BOTH day of month and day of week are restricted, the job runs when EITHER matches, not both. So 0 0 13 * 5 runs on the 13th and on every Friday, which is not what the person writing it usually meant.

Where crontabs live, and who may have one

A user's crontab is edited with crontab -e, listed with crontab -l and removed with crontab -r; the files themselves live under /var/spool/cron/ and are not meant to be edited directly. The SYSTEM crontab, /etc/crontab, and the files in /etc/cron.d/ have an extra field between the schedule and the command: the user to run as. Forgetting it is why a hand-written /etc/cron.d file silently fails.

The directories /etc/cron.hourly, cron.daily, cron.weekly and cron.monthly hold executable scripts run on that cadence with no schedule syntax at all. What actually runs them is run-parts, called once per directory from a single crontab entry, and it decides for itself which entries are eligible — which is the source of a classic silent failure. Debian's naming rule accepts only letters, digits, underscores and hyphens, so a script dropped in as backup.sh is skipped for the dot in its name while everything beside it runs, with nothing logged to say so. Packages drop the extension entirely for that reason. anacron exists for machines that are not on all the time: it tracks when a job last ran and catches up after a boot, which plain cron never does. Access is controlled by /etc/cron.allow and /etc/cron.deny — if allow exists, only the users in it may use cron; otherwise everyone except those in deny.

at runs a command once at a given time — at 22:00, at now + 1 hour — with atq listing pending jobs and atrm removing one; at.allow and at.deny work the same way as their cron counterparts. systemd timers are the newer mechanism: a .timer unit paired with a .service unit, listed with systemctl list-timers, and they can trigger relative to boot or to the last run in a way cron cannot express.

systemd-run is the way to get one of those without writing a unit file at all: it builds a TRANSIENT unit on the fly and starts it. With no timer option the command runs at once; with one, systemd-run creates a transient .timer as well and the command runs when it fires. So systemd-run --on-active=15m /usr/local/bin/report.sh is the answer on a systemd host with no atd installed and nothing to be installed. The timer options divide into monotonic ones — --on-active, --on-boot, --on-startup, --on-unit-active — which take a time SPAN such as 15m or 90s, and --on-calendar, which takes systemd calendar syntax such as an absolute date and time. Handing a span to --on-calendar is the mistake the distractors are built from.

A cron job runs with a minimal environment and its output is mailed to the owner. Redirecting to a file or to /dev/null is how that mail is silenced, and it is why a job that "does nothing" is often working perfectly and failing to find a command that is not in cron's PATH.