Where are cron errors logged?

Question

If I setup cron jobs incorrectly they appear to silently fail. Where should I look for an error log to understand what went wrong?

Answer 1

As others have pointed out, cron will email you the output of any program it runs (if there is any output). So, if you don't get any output, there are basically three possibilities:

1. crond could not even start a shell for running the program or sending email
2. crond had troubles mailing the output, or the mail was lost.
3. the program did not produce any output (including error messages)

Case 1. is very unlikely, but something should have been written in the cron logs. Cron has an own reserved syslog facility, so you should have a look into /etc/syslog.conf (or the equivalent file in your distro) to see where messages of facility cron are sent. Popular destinations include /var/log/cron, /var/log/messages and /var/log/syslog.

In case 2., you should inspect the mailer daemon logs: messages from the Cron daemon usually appear as from root@yourhost. You can use a MAILTO=... line in the crontab file to have cron send email to a specific address, which should make it easier to grep the mailer daemon logs. For instance:

MAILTO=my.offsite.email@example.org
00 15 * * *  echo "Just testing if crond sends email"

In case 3., you can test if the program was actually run by appending another command whose effect you can easily check: for instance,

00 15 * * * /a/command; touch /tmp/a_command_has_run

so you can check if crond has actually run something by looking at the mtime of /tmp/a_command_has_run.

Answer 2

The default cron configuration will send you a mail with the output of your program. If this fails, you could try wrapping your failing program in a shell script that ensures that the program does not fail, and you could further log the output.

This is a configurable setting on some cron implementations.

Answer 3

You can always explicitly send the job output to a log file:

0 8 * * * /usr/local/bin/myjob > /var/log/myjob.log 2>&1

Keep in mind that this will supercede the mail behaviour that has been mentioned before, because crond iself won't receive any output from the job. If you want to keep that behaviour you should look into tee(1).

Answer 4

Cron logs basic info to /var/log/messages, but mails any program output to the invoking user.

Answer 5

You should get email from crond when the job either fails to run or when the job returns a nonzero exit code. Try typing:

$ mailx

at the command prompt.

mailx(1) is the basic mail reading program on most every Unixlike system. It is very primitive by modern standards, but you can pretty much count on it to always be available. Other, better mail agents may be available, but there are enough of them that you never know which one is installed on some random machine you happen to be using.

Note that unless you have configured your system as an Internet email server, this mail subsystem is used only within the machine. You can send email to and receive from other users on the machine, but you may not be able to send email out to the world, and email from the outer world certainly won't be able to come to your machine.

Answer 6

If you aren't seeing the mails, or if you are spamming root@yourcompany with the errors, try sending the output to Syslog instead:

*/5 * * * * yourcronjob 2>&1 | /usr/bin/logger -t yourtag

Then, wait for the cronjob to run and look for the error in /var/log/messages (or /var/log/user.log on some systems).

This works great for errors messages which are only 1-2 lines long, such as "yourcronjob: command not found". It also makes use of your existing syslog infrastructure (Logrotation, central syslogging, Splunk, etc.) It also reduces email spam to root.

It may not be a good solution if your cronjob generates hundreds of lines of output.

Answer 7

I use vixie-cron, so I don't know if this applies to everything. But I have a dead.letter file that contains all the output of the job.

In my /root/ folder I have crons.cron which I set as my crontab by running crontab /root/crons.cron. dead.letter will be created in /root/ as well.

Edit I just Google'd dead.letter, and it's an undeliverable mail. It has nothing to do with cron apparently. If you don't have mail set up correctly (like me), you'll have the file.