cron: Scheduling Jobs in Linux

The cron daemon

Cron runs as a background daemon, typically called crond on Red Hat-based systems. On Debian-based systems the package is usually called cron. Either way the daemon starts at boot, stays running in the background and wakes up once per minute to check whether any scheduled jobs are due.

The checking mechanism is straightforward. Every minute the daemon reads all active crontab files, compares each entry against the current time and launches any jobs whose schedule matches. The job runs as a subprocess, inherits a minimal environment and produces output that gets mailed to the owning user unless you redirect it somewhere else.

The crontab syntax

Each line in a crontab file that describes a scheduled job follows the same format: five time fields followed by the command to run. The fields are positional. Getting them in the wrong order is the most common mistake people make when writing cron entries for the first time.

Each field also accepts special characters. An asterisk means every valid value. A comma separates a list of values. A forward slash after an asterisk expresses a step interval. The expression */5 in the minutes field means every five minutes. A hyphen defines a range, so 1-5 in the day-of-week field covers Monday through Friday.

Reading cron expressions

The best way to get comfortable with the syntax is to read real examples. Work through each one from left to right: minute, hour, day of month, month, day of week.

Special strings

Most cron implementations support a set of named shortcuts that replace the five-field syntax for common intervals. They are easier to read at a glance and less likely to be mistyped.

The @reboot entry is worth knowing. It runs the command once each time the system boots, which makes it useful for things that need to start at boot but do not warrant a full systemd service unit.

Managing crontabs

Each user on the system can have their own crontab. The crontab command is how you create, view and edit it. User crontabs are stored under /var/spool/cron/ but you should never edit those files directly. Always go through the crontab command so the daemon is properly notified.

System-wide cron locations

User crontabs handle per-user scheduled tasks. System-level scheduled work lives in a different set of locations under /etc/. Some of these are directories where you drop scripts. Others are files with full crontab syntax that packages maintain directly.

The main system crontab lives at /etc/crontab. It uses the same five time fields but adds a username column after them so the daemon knows which user to run each command as. This is the file that ties together the drop-in directories.

Environment variables and output

Jobs run by cron inherit a minimal environment. The PATH variable is much shorter than what you get in an interactive shell, which means commands that work fine when you type them manually can fail silently inside cron because the binary is not in the restricted path.

The safest approach is to use absolute paths for every binary in your cron scripts. Alternatively, set PATH explicitly at the top of your crontab file. Any variable assignments at the top of the file apply to all jobs below them.

By default, any output from a cron job gets emailed to the user who owns the crontab. On most servers there is no mail daemon configured, so that output disappears. Setting MAILTO="" suppresses it entirely. A better approach is to redirect output explicitly in the job definition using >> /path/to/logfile 2>&1 so you have something to read when a job misbehaves.

Common pitfalls