62

I prefer to stick scheduled tasks in /etc/crontab so I can see at a glance what's scheduled to run, regardless of which user the task runs as.

The only gotcha is that the format isn't validated on save, unlike crontab -e -- so a stray character can quietly break the entire cron.

Is there a way to validate the /etc/crontab format before/after save?

Ben K.
  • 2,379
  • 4
  • 18
  • 15
  • 6
    If, like me, you came here looking for a simple (non-scriptable) way to tell you whether you'd got your cron entry right, you might be interested in http://www.cronchecker.net — it's an online validator for cron entries with human-friendly output. – Matt Gibson Dec 20 '14 at 11:18

8 Answers8

44

The only reliable way I found is to check the log.

cron checks /etc/crontab every minute, and logs a message indicating that it has reloaded it, or that it found an error.

So after editing, run this:

sleep 60; grep crontab /var/log/syslog | tail

Or, to not wait a full minute, but only until the next minute + 5 seconds:

sleep $(( 60 - $(date +%S) + 5 )) && grep cron /var/log/syslog | tail

Example output with an error:

Jan  9 19:10:57 r530a cron[107258]: Error: bad minute; while reading /etc/crontab
Jan  9 19:10:57 r530a cron[107258]: (*system*) ERROR (Syntax error, this crontab file will be ignored)

Good output:

Jan  9 19:19:01 r530a cron[107258]: (*system*) RELOAD (/etc/crontab)

That's on Debian 8. On other systems, cron might log to a different file.

(I thought I could avoid hunting for the right log file by using systemd's journalctl -u cron, but that didn't show me these log entries, and actually seems to have stopped logging cron events 2 days ago for some reason)

mivk
  • 4,004
  • 3
  • 37
  • 32
16

Another more recent solution is the python script chkcrontab

Dave Wongillies
  • 462
  • 4
  • 8
11

Wicked cool shell scripts has a shell script that validates crontab files.

You can get the zip archive containing the script here

The script is called verifycron

Gohu
  • 121
  • 1
  • 1
  • 7
Ludwig Weinzierl
  • 1,180
  • 1
  • 11
  • 22
  • 1
    Link doesn't work anymore as of 11 jan 2017. – Epskampie Jan 11 '17 at 11:37
  • Someone fixed the link. In the zip-file it is located in "wicked_cool_shell_scripts_2e-master/6/48-verifycron". Use it with `./48-verifycron /var/spool/cron/crontabs/root` to verify your user root crontab-file. – MadMike May 25 '21 at 12:08
6

I found this cool solution here: https://crontab.guru

It doesn't just validate the crontab, it tells you explicitly what and when the crontab will run, and highlights where errors are.

JDS
  • 2,598
  • 4
  • 30
  • 49
2

On Ubuntu, it seems like I can just run:

crontab path/to/crontab/file

NOTE: this has the side effect of starting this cronjob (thanks @NZD)

If the file is invalid, I will an error, like:

"crontab":11: bad minute
errors in crontab file, can't install.
conradkleinespel
  • 125
  • 7
  • 1
    this command does check the crontab file, but at the same time installs it (if it contains no errors). This is probably an unwanted side-effect for the OP. – NZD Dec 19 '16 at 01:18
  • Thanks @NZD, I've added this to my reply to make sure the OP is aware of that. – conradkleinespel Dec 19 '16 at 11:08
  • @conradk the command doesn't start the cronjob, it overwrites the user's existing crontab file with the file provided. – MadHatter Dec 19 '16 at 11:59
  • This doesn't actually work for all possible problems with the crontab; it will catch some glaring problems, but it doesn't catch this, for example: `* 4/0 * * /bin/myscript.sh` -- the `4/0` is invalid. but isn't caught by this method – JDS Jul 31 '17 at 14:23
  • @JDS Isn't it a step value? Is a step value of `0` forbidden? https://unix.stackexchange.com/questions/32027/whats-the-meaning-of-the-slash-in-crontab – conradkleinespel Aug 01 '17 at 12:18
  • @conradkdotcom pretty sure 0 in the denominator would be prohibited. (it is certainly prohibited in arithmetic.). I'm pretty sure `4/0` doesn't work in a crontab – JDS Aug 01 '17 at 17:15
  • I find this ver usefull, as long as you are aware that you are overwiriting your cron file. – Crami Aug 17 '20 at 07:34
  • My cron was wiped after typing this. Almost reset. *sadness* – rockstardev Nov 20 '21 at 13:18
0

Tailing the logs is the best solution I feel, as pointed out by @mivk in their answer.

journalctl is a good option too:

vedant@zebronics:~$ journalctl -u cron.service 
... <hit shift+G to goto last line>
Nov 03 10:33:01 zebronics cron[627]: (*system*) RELOAD (/etc/crontab)

(Hit shift+G to go the latest line in journal)

Vedant Agarwala
  • 99
  • 3
0

This has worked the best for me:

systemctl restart cron; journalctl -u cron --lines 10

Forcing the restart ensures that cron checks the syntax immediately, instead of waiting 60 seconds. If there are any errors, journalctl will show them.

Martin von Wittich
  • 196
  • 13
-1

run crontab -T path/to/crontab

If you want to automatically do it before/after, you can write your own visudo style wrapper, such as

$EDITOR /etc/crontab
crontab -T /etc/crontab

Personally, since breaking the crontab is not as bad as breaking sudoers, I think it's fine to just print the message, but you could also everything to a tempfile if you wanted.

Zachary Vance
  • 99
  • 1
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Nov 09 '21 at 18:13
  • 1
    What OS is this valid for? My crontab command on Ubuntu does not have the -T flag at all – MightyPork Jun 09 '23 at 15:13
  • This is from "cronie" cron by Paul Vixie and Colin Dean. I am on Arch Linux. Info is from my man page. – Zachary Vance Jun 09 '23 at 18:52