Fix “errors in crontab file, can’t install”

This message means crontab rejected the file it was asked to install. Read the specific error immediately above it: that usually names a line and a field, such as “bad minute” or “bad day-of-week.” Fix the candidate before trying again.

An unsuccessful installation normally preserves the previous table. The candidate's valid-looking lines are not a partial update.

Keep a backup before making changes

Save the installed table to a private file, and keep a failed export from overwriting a useful backup:

umask 077
backup=$(mktemp "${TMPDIR:-/tmp}/crontab-backup.XXXXXX") || exit 1
if crontab -l > "$backup"; then
    printf 'Backup saved to %s\n' "$backup"
else
    rm -f "$backup"
    printf 'No backup created; inspect the crontab error.\n' >&2
    exit 1
fi

A nonzero result may mean the account has no crontab, but it can also indicate another problem. Read the error rather than treating every failure as an empty schedule.

Inspect the rejected file

nl -ba jobs.cron
LC_ALL=C sed -n 'l' jobs.cron

For common Vixie-derived cron, check the five fields against these ranges:

Names and extensions depend on the implementation. Check the ranges and order of the five schedule fields, then the command that follows them. The command may contain spaces, so a valid job is not limited to six whitespace-separated words. Blank lines are allowed, as are supported environment assignments and macro entries.

Common problems include minute 60, an invalid range, an unsupported step or macro, a pasted line break, CRLF endings, non-ASCII spaces, and a missing final newline. Put explanatory comments on their own lines. Debian cron accepts optional spaces around = in environment assignments; do not diagnose those spaces alone as a universal syntax error.

Choose the correct file format

A user crontab uses:

0 2 * * * /home/appuser/jobs/nightly.sh

A system cron file uses:

0 2 * * * appuser /home/appuser/jobs/nightly.sh

Use crontab -e for a user's table or your configuration-management process for /etc/crontab and /etc/cron.d/. Do not edit cron's user spool directly.

Check, install, then observe

If your installed implementation offers a syntax-only option, use it: Cronie documents -T, while Debian cron versions documenting dry-run mode use -n. These flags are not interchangeable. Consult man crontab before invoking either.

After review, crontab jobs.cron installs the complete candidate for the current user. It replaces that user's table. Verify with crontab -l, then check the next intended execution and the script's result.

An accepted schedule cannot prove the command exists or will succeed. Write runtime output to an account-writable log and record completion status separately from cron's launch events.

Common questions

Can I ignore the error because most lines are correct? No. Correct the reported problem and confirm successful installation of the whole candidate.

Does cron support a 90-second interval? Traditional system cron does not express this directly. Use a suitable timer or application scheduler, and decide whether the interval is measured from the last start or the last completion.

Should I restart the daemon? A restart does not repair invalid syntax. Normal supported crontab changes are detected without one.

References

• Debian crontab syntax
• Debian cron daemon behavior
• Debian crontab installation and dry-run options