Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I have a fresh install of Ubuntu 12.04.1 LTS an a number of servers.

I have not added any cron jobs or edited my crontab on those servers, however, at around the same time for each machine, I get a 75% CPU spike and the following info in my syslog at the time of the spike:

CRON[8380]: (CRON) info (No MTA installed, discarding output)

I have mono-complete installed and am running a service stack webserver.

What is the best way for me to stop this from happening? I would like to be able to remove the CPU spike.

share|improve this question
Every day at 6:25? Those are scripts from /etc/cron.daily/. I have only one trying to send mail: popularity-contest. Look though your scripts and see which script is trying to send mail? That should narrow it down. Then 'chmod 0644 /etc/cron.daily/script-name' to prevent execution. –  user8290 Nov 27 '12 at 16:11

3 Answers 3

up vote 21 down vote accepted

Linux uses mail for sending notifications to the user. Most Linux distributions have an mail service (including an MTA) installed. Ubuntu doesn't though.

You can install a mail service, postfix for example, to solve this problem.

sudo apt-get install postfix

Or you can ignore it. I don't think the inability of cron to send messages has anything to do with the CPU spike (that's linked to the underlying job that cron is running). It might be safest to install an MTA and then read through the messages (mutt is a good system mail reader).

share|improve this answer
Is postfix a good thing to install? Which MTA is easiest to use? –  endolith Nov 26 '13 at 4:34

This happens because your cron jobs are producing output and then the cron daemon tries to email that output to you (i.e. root). If you don't need that output, the easiest way to solve this is to discard it at the crontab:

sudo crontab -e

and add >/dev/null 2>&1 to every job

share|improve this answer
The problem with this approach is it doesn't explain the high CPU usage. Cron is clearly trying to be communicative and this is essentially just ignoring the output. I'd be more inclined to handle the output than discard it, just in case there's useful debug info. –  Oli Jan 2 at 14:39

One side effect of adding /dev/null 2>&1 to the cron job command, is that it will discard both STDERR and STDOUT (Standard Error as well as Output). This works find if you don't want any emails from cron. But if you want your errors to be emailed to you, use >/dev/null instead. Read this blog post for more explanation.

You'll still need to install a MTA (message transfer agent) to send the error emails though. Postfix is simple enough to install with: sudo apt-get install postfix

share|improve this answer
As far as I understood '>/dev/null' will only send them, and '>/dev/null 2>&1' will doscard all errors? What would I have to use to get errors in log but no mails? I now get no mails (as I want it) but the ugly 'no MTA…' –  Pit Feb 5 at 12:31
afaik, there's no way to log the output other than to send it to emails. The closest thing you can do is to set up postfix for local mail delivery (if you run "sudo apt-get install postfix" it prompts you whether you want to set up local delivery. While this looked like a pain initially, it actually works a lot better. Whenever I log in via ssh, I see a new email on the machine if a previous job has failed. I find it more convenient than having to check the log. –  paneer_tikka Feb 7 at 4:32
I think this could be ok for me. Thanks –  Pit Feb 14 at 8:51

Your Answer


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.