Web Developers and Cron jobs

Dear other web developers ….

if you’re going to add a cron job to a (web) server, please make sure any output is sent to a valid email address (or log file) which is monitored….

This can be achieved through a number of ways :

Specifying a MAILTO=someone@somewhere at the top of the cron file (see ‘man 5 crontab’ for more information on this).

Editing /etc/aliases and making sure the user the cron job is running as has their email delivered somewhere ‘real’ (e.g. support@yourCompany) (this is dependent on the MTA configuration on the server though).

Redirect output from cron jobs to named files, and then have a daily report generated on these (E.g. using logcheck).

Having cron job output ‘disappear’ in the ether only results in errors going unnoticed, and unexplained behaviour on the site(s) in the future.

So – as an example – a ‘bad’ cron file may look like the following :

 ## m h dom mon dow command

0,15,30,45 * * * * bash /path/to/command/cron/instance.sh > /dev/null 2>&1

Problems :

StdErr/Errors are suppressed (sent to /dev/null)

We’ll never know if this cron job has run / is running correctly – if /path/to/command is moved in the future, the error will be suppressed.

A better cron file would look like :



MAILTO=support@example.org

0,15,30,45 * * * * bash /path/to/command/cron/instance.sh >/var/log/cron.log

Errors aren’t suppressed – so should get emailed to support@example.org

StdOut is logged to a file – for later review (just remember to ensure the log file is getting rotated through logrotate)

MAILTO is specified

(This minor rant is triggered by discovering a web server sending ~700 emails a day to a non-existent mailbox … most of which look like error reports which ought to be investigated/fixed).

Web Developers and Cron jobs

Leave a Reply Cancel reply

Share

Search

Customer Quotes