I often see cron jobs configured to pipe all output to /dev/null to get rid of it. Other times the emails cron sent are piling up and ignored due to alert fatigue.
It seems a bit counterintuitive to ignore output from tasks you are relying on to run successfully. If something goes wrong, you should at least be able to figure out what happened.
That’s why it’s a good idea to log cron output using the logger shell command. It sends your log messages straight to the system log.
This has a couple of great benefits: it works on most Linux distro’s out of the box, you don’t have to worry about tracking and rotating another log file and it fits nicely into the existing logging infrastructure.
And above all, it’s super easy to set up! Instead of piping all output to /dev/null, pipe it to the logger command. Example:
echo "This command ran successfully" | /usr/bin/logger -t example
Tail the syslog file to see it in action:
sudo tail -f /var/log/syslog
You’ll see your test notice appear:
[email protected]:# tail -f /var/log/syslog
Mar 28 16:13:28 ubuntu example: This command ran successfully
So, if your cron job is set up to ignore all output, like this:
*/5 * * * * myscript.sh >/dev/null 2>&1
update it to send the info to the syslog using logger:
*/5 * * * * myscript.sh 2>&1 | /usr/bin/logger -t myscript
I like this approach to log output for most cron jobs. It’s easy to configure and I can look for certain output in syslog to be notified of any problems. And because all output is redirected to logger, cron will not send me emails anymore either.