Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We all know the right way to handle output from cron jobs is to redirect it to a file:

0 * * * * /bin/date >> /var/log/date.log 2>&1

However, sometimes admins are lazy, forgetful, or ignorant and don't put in those redirects; in this case the output of the job gets mailed to $MAILTO or the owning user or root. On some of the boxes I manage, mail is disabled, so this output goes into a black hole. What I'm wondering is, is there any way to tell cron to take any job output and instead of mailing it, throw it into a catch-all log file somewhere? I'm using Ubuntu (8.04 but migrating to 9.04). There's a hint of such a solution in this random Google result, but I think the OP might have been confused about cron output vs. the output of cron jobs.

I'm open to solutions that involve a bit of scripting or hacking, but ideally this would be a config bit I could set somewhere. I don't see any hints in man cron. Thanks!

share|improve this question
add comment

7 Answers

Never heard of such a setting for cron, so I would take the scripting route.

Create a cron job to patrol /var/spool/cron/*, and append the redirect to any job that does not have one.

share|improve this answer
add comment

The short answer is no, cron mails to the owner of the crontab by design. In the standard cron there is no way to change this.

The best I can think of is to configure the MTA's on the machines where you want this behavior to dump the mail in to a log file instead of a user mailbox.

share|improve this answer
add comment

I don't think what you're asking for is actually possible with Ubuntu (or any other) cron.

Aside from geekmonkeys idea, you could also set $MAILTO to a local account and route the output through procmail.

share|improve this answer
add comment

Another option would be to create a shell script called cron_wrapper or something, and have it just do something like this:

#!/bin/sh

eval "$* >> /var/log/cronlog.log"
exit $?

Then, all of your crontabs just need something like this:

* * * * * /usr/local/bin/cron_wrapper echo hello

Note I haven't tested this code, it's just an idea.

share|improve this answer
1  
That doesn't solve the problem. If people can't remember to set MAILTO or to redirect stdout to a file, they're not going to remember to to run stuff through the wrapper. –  Kamil Kisiel Aug 19 '09 at 20:07
add comment

I am not sure what you mean exactly when you say "mail is disabled". But maybe you could set up an alias in /etc/aliases that is directed to a pipe? Something like

root: "|/bin/cat >> /var/log/cron.log"
share|improve this answer
    
root: /var/log/cron.log doesn't work? feep.net/sendmail/tutorial/intro/aliases.html –  endolith Nov 29 '12 at 2:09
    
Neither does anything for me. –  endolith Nov 29 '12 at 2:33
add comment

I don't know what is the "standard cron". There are lots of cron daemons, different distros use different ones. Vixie cron is most widely deployed, so that's probably what you meant. But on some distros, it wouldn't be the default.

I've taken over development of Dillon's cron (dcron), which is the default on Arch Linux. Other distros use it too, but I don't know if it's the default anywhere else. dcron has an invocation option -M to specify that you want to use a custom script instead of sendmail. The script gets called with no arguments, and with a few email headers and the &> output of any cronjobs as stdin. (If there's no &> output, the script isn't called.)

share|improve this answer
add comment

why don't we set MAILTO="" in particular user's crontab. This will disable logging of mail messages in /var/spool/mail/

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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