59

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?

Improve this question
1
  • 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 cronchecker.net — it's an online validator for cron entries with human-friendly output.
    – Matt Gibson
    Dec 20, 2014 at 11:18

7 Answers 7

Reset to default
41

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)

Improve this answer
1
  • 1
    Tested on FreeBSD 10.3. Works like a charm, just replace log path with /var/log/cron
    – Jette
    Aug 5, 2019 at 8:15
16

Another more recent solution is the python script chkcrontab

Improve this answer
2
  • 2
    It doesn't check users' cronjobs yet
    – userlond
    Oct 19, 2015 at 7:22
  • It told me that cron wouldn't run the file because it contains dots in the file name. Thanks!
    – cweiske
    Aug 19, 2021 at 7:26
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

Improve this answer
2
  • 1
    Link doesn't work anymore as of 11 jan 2017.
    – Epskampie
    Jan 11, 2017 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, 2021 at 12:08
5

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.

Improve this answer
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.
Improve this answer
8
  • 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, 2016 at 1:18
  • Thanks @NZD, I've added this to my reply to make sure the OP is aware of that.
    – conradkleinespel
    Dec 19, 2016 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, 2016 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, 2017 at 14:23
  • @JDS Isn't it a step value? Is a step value of 0 forbidden? unix.stackexchange.com/questions/32027/…
    – conradkleinespel
    Aug 1, 2017 at 12:18
0

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.

Improve this answer
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.
    – Community Bot
    Nov 9, 2021 at 18:13
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)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.