Mastering crontab: Common Pitfalls and Practical Solutions

What is crontab?

crond is the Linux daemon that runs scheduled tasks, similar to Windows Task Scheduler. It checks every minute for entries in user crontabs ( /var/spool/cron) and the system‑wide /etc/crontab, executing commands when the time fields match.

crontab command syntax

crontab [-u user] [file]
crontab [-u user] [-e|-l|-r|-i]

Options: -u user: operate on another user’s crontab (requires root). file: load commands from a file instead of stdin. -e: edit the crontab. -l: list the crontab. -r: remove the crontab. -i: ask for confirmation before removal.

crontab file format

A crontab line consists of six fields: minute hour day month week command. The first five define the schedule, the sixth is the command to run. minute hour day month week command Field details: minute: 0‑59 hour: 0‑23 day: 1‑31 month: 1‑12 week: 0‑7 (0 or 7 = Sunday) command: any shell command or script

Special characters: *: all possible values ,: list separator (e.g., 1,2,5) -: range (e.g., 2-6) /: step values (e.g., 0-23/2 runs every 2 hours)

Common examples

0 */3 * * * /usr/local/apache2/apachectl restart

Restart Apache every 3 hours. 30 3 6 * * /webdata/bin/backup.sh Run /webdata/bin/backup.sh at 03:30 every Saturday. 0 0 1,20 * * fsck /dev/sdb8 Run fsck on /dev/sdb8 on the 1st and 20th of each month.

10 5 */5 * * echo "" >/usr/local/apache2/log/access_log

Clean Apache access logs on the 5th, 10th, 15th, 20th, 25th, and 30th of each month at 05:10.

System‑wide /etc/crontab

System‑wide crontab defines environment variables and system tasks. Example:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

The first four lines set the environment for all cron jobs; the remaining lines schedule hourly, daily, weekly, and monthly tasks.

Debugging and validation

Validate a cron expression with the online parser at https://crontab.guru. Check execution logs with /var/log/cron or journalctl -u crond. Verify the daemon is active using systemctl status crond.service (systemd) or service crond status (SysVinit).

Typical pitfalls and solutions

1. Environment variables

crontab runs with a minimal PATH (usually /usr/bin:/bin). Commands located elsewhere (e.g., /usr/local/bin/php) will fail. Use absolute paths or load the user’s profile before the command:

* * * * * source $HOME/.bash_profile && command

2. Time field mistakes

Writing * 2 * * * runs every minute during the 2 am hour. To run a command once at 02:00, use:

0 2 * * * command

3. The % character

The first % starts standard input; subsequent % are treated as newlines. Escape a literal percent sign with a backslash:

* * * * * echo "Special character \%" >> /tmp/file

4. Output redirection and mail

Without redirection, a job’s stdout/stderr is mailed to the user (controlled by MAILTO). Suppress mail and discard output with:

MAILTO=""
0 * * * * /bin/date >/dev/null 2>&1

Note that some output may still go to /var/spool/clientmqueue; explicit redirection is recommended.

5. Debugging workflow

Check /var/log/cron or journalctl -u crond to confirm the job ran.

Verify the cron expression, environment variables, special characters, and file permissions.

Ensure the crond service is active ( systemctl status crond or service crond status).

Redirect output to a log file to capture errors, e.g.:

* * * * * python /path/script.py >> /tmp/script.log 2>&1

Review the log to pinpoint issues such as “command not found”, which often indicates a missing PATH entry.