Fix a missing newline at the end of a crontab

A crontab entry must end with a newline character, including the final entry in the file. If the last line ends immediately after the command, cron may report “missing newline before EOF” and reject the candidate file.

A rejected crontab installation normally leaves the previously installed table in place. Do not assume that earlier lines from the rejected candidate have been installed, or that only its final job is affected.

Repair a user crontab

Open it through the supported editor:

crontab -e

Make sure the last line ends with a newline, save, and check that installation succeeds. An extra visible blank line is not required; what matters is the newline byte at the end of the last line.

For a candidate file, inspect its last byte:

tail -c 1 jobs.cron | od -An -tx1

A nonempty file ending correctly prints 0a. If it is missing, append a newline:

printf '\n' >> jobs.cron

Review the whole candidate before installing it. crontab jobs.cron replaces the current user's entire table; it does not append the file's jobs.

Generate files with the right format

A user crontab has five schedule fields followed by the command:

printf '%s\n' '0 3 * * * /opt/jobs/backup.sh' > jobs.cron

Files in /etc/cron.d/ use an additional username field. A system-file candidate would instead contain:

printf '%s\n' '0 3 * * * backup /opt/jobs/backup.sh' > backup.cron

Install that candidate through your system configuration process, with the ownership, permissions, filename and environment required by the distribution. Do not install a system-format file using crontab filename.

Inspect system files without editing them

This shell loop checks nonempty regular files and skips missing paths:

for file in /etc/crontab /etc/cron.d/*; do
    [ -f "$file" ] && [ -s "$file" ] || continue
    last=$(tail -c 1 "$file" | od -An -tx1 | tr -d ' \n')
    [ "$last" = 0a ] || printf 'Missing final newline: %s\n' "$file"
done

Read permissions are required. Fix the configuration source as well as the installed file so the next deployment does not recreate the problem. Do not directly edit the user-crontab spool.

Confirm the job can run

An accepted file proves that cron accepted its syntax, not that the command has valid permissions, dependencies, or a working output destination. Check the next scheduled launch and the application's completion record. With centralized task logs, keep scheduling events separate from job results.

Common questions

My editor says “noeol.” Is that relevant? Yes. It commonly means the final line has no end-of-line character. Configure the editor to save a final newline.

Why does a file work in my crontab but fail under /etc/cron.d/? System cron files need a username field; user crontabs do not. They may also have different environment and file-permission requirements.

Should I restart cron after every edit? Supported cron implementations detect ordinary crontab changes. Confirm installation and logs first; restarting does not repair an invalid file.

References

• Debian crontab syntax
• Debian cron daemon behavior