No MTA installed, discarding ouput
By default, the output of each cron job is collected by cron, and sent via email each time the job completes.
What causes this error
If you see (CRON) info (No MTA installed, discarding output) messages in your syslog it means that there is output from your cron job, but your server does not have a Message Transfer Agent installed to process the output into an email.
This is not a problem with your cron job itself, and does NOT mean that your cron job is failing.
How to fix No MTA installed errors
There are 3 ways you can fix this error:
1. Install an MTA like the popular postfix . This can be installed in most cases from a package manager. For example, on Ubuntu you may run:
sudo apt-get install postfix If you select local installation, the output from your cron jobs will be relayed to a local «mailbox» that you can easily tail:
sudo tail -f /var/mail/cron user> 2. If you don’t care about cron emails, you can silence the error by disabling emails from your crontab. The easiest way to do this is to add the following to the top of the crontab file:
3. The final option is simply to ignore this error. It is not a fatal error, and does not impact the success of your cron job itself.
Are your cron jobs running?
There are no cron configuration options for monitoring and alerting. Monitor your cron jobs with Cronitor to easily collect output, capture errors and alert you when something goes wrong.
Crontab not restarting process
I am trying to setup a crontab to run 6 python data scrapers. I am tired of having to restart them manually when one of them fails. When running the following:
> ps -ef | grep python ubuntu 31537 1 0 13:09 ? 00:00:03 python /home/ubuntu/scrapers/datascraper1.py # m h dom mon dow command * * * * * pgrep -f /home/ubuntu/scrapers/datascraper1.py || python /home/ubuntu/scrapers/datascraper1.py > test.out Then I hit control+X to exit and hit yes to save as /tmp/crontab.M6sSxL/crontab . However it does not work in restarting or even starting datascraper1.py whether I kill the process manually or if the process fails on its own. Next, I tried reloading cron but it still didn’t work:
Finally I tried removing nohup from the cron statement and that also did not work. How can I check if a cron.allow or cron.deny file exists? Also, do I need to add a username before pgrep? I am also not sure what the «> test.out» is doing at the end of the cron statement. After running
ubuntu@ip-172-31-29-12:~$ grep CRON /var/log/syslog Jan 5 07:01:01 ip-172-31-29-12 CRON[31101]: (root) CMD (pgrep -f datascraper1.py || python /home/ubuntu/scrapers/datascraper1.py > test.out) Jan 5 07:01:01 ip-172-31-29-12 CRON[31100]: (CRON) info (No MTA installed, discarding output) Jan 5 07:17:01 ip-172-31-29-12 CRON[31115]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 5 08:01:01 ip-172-31-29-12 CRON[31140]: (root) CMD (pgrep -f datascraper1.py || python /home/ubuntu/scrapers/datascraper1.py > test.out) Since there is evidence of Cron executing the command, there must be something wrong with this command, (note: I added the path to python):
pgrep -f datascraper1.py || /usr/bin/python /home/ubuntu/scrapers/datascraper1.py > test.out Which is supposed to check to see if datascaper1.py is running, if not then restart it. Since Cron is literally executing this statement:
(root) CMD (pgrep -f datascraper1.py || python /home/ubuntu/scrapers/datascraper1.py > test.out) root pgrep -f datascraper1.py The program 'root' is currently not installed. You can install it by typing: sudo apt-get install root-system-bin crontab error with (No MTA installed) but I use >/dev/null 2>&1
What is the owner of /var/backup/all ? As you use the full path with mysqldump , could you to use it too with gzip ?
Thanks you for help. The owner of /var/backup/all is root (I don’t know how to create folder with out sudo ) I which mysqldump is /usr/bin/mysqldump and which gzip is /bin/gzip .
3 Answers 3
Of course, the error is that you don’t have a mailer (sendmail,postfix, etc) implemented and active.
That being said your other problem is that the >/dev/null 2>&1 ONLY only applies/associates to the LAST command in this case gzip. Thus there must be some type of output going to STDERR for your mysqldump.
The correct way to do what I think you want is:
* * * * * (command | command ) >/dev/null 2>&1 Thanks you for help. But I have a problem that I think about permission. It didn’t create a backup file I use crontab -e with vagrant user but my folder is create by root (via sudo) so I thinking about chown user for folder right ?
@mdpc The output of the last command, gzip , goes to the dump file. It makes no sense to somehow write filedescriptor 1 to /dev/null too. The >/dev/null 2>&1 applies to the error stream of gzip only, that’s right.
It sets the descriptor to a designated default until changed by an underlying command. This format would be good so that in the future if other commands and such are added to the line, you will not have to worry about this particular problem again.
at the beginning of your crontab file and that will prevent it from trying to send email.
If the user running the crontab command is vagrant , and the directory where the output is written to is owned by root , and has permissions 755 , it can not be written to.
sudo chown vagrant /var/backup/all
may fix that.
To check whether that’s the problem, try writing to a file in /tmp instead.
But there is another problem: A command like
mysqldump mydb | gzip > database.sql.gz >/dev/null 2>&1
writes the database dump to database.sql.gz and to /dev/null .
The 2>&1 copies the error messages to the standart output, that means it also writes the error messages to database.sql.gz . It writes error message text just some where in between the compressed data, so the compressed file will be broken. Note it may work well when testing — as the problem only occurs when something is written to the standard error stream. The output to stderr may be just a warning, while everything else works.
I assume you intend to write the compressed database dump to the sql.gz file, and the errors to /dev/null . For this, just keep the output streams separate, by not copying the error stream to the output stream. And direct them to the files like this:
mysqldump mydb | gzip > /var/backup/all/database_`date +%Y-%m-%d`.sql.gz 2>/dev/null The error message «(No MTA installed, discarding output)» is cron telling you that it can not send you the error output. That will be no problem in the end as you redirect errors to /dev/null anyway, there will be nothing to send. But I suspect that currently there are error messages to send, that should confirm my findings above.
«(CRON) info (No MTA installed, discarding output)» error in the syslog
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.
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.
14 Answers 14
Linux uses mail for sending notifications to the user. Most Linux distributions have a mail service including an MTA (Mail Transfer Agent) 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).
It is worth pointing out that for use with cron (that is if you don’t want to actually send email outwards) during the installation procedure you should answer to configure for local use only.
the only way I know to check mail is mail provided by mailutils (debian), if there a better way built in to postfix?
Is postfix the one that doesn’t actually send emails over the internet but creates a local mailbox that you can check from the command line? Would be good to mention that. (Yep it is, used this answer to verify on my other server: serverfault.com/a/100743 )
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:
and add >/dev/null 2>&1 to every job:
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, even though this is an old question, I am experiencing the same exact issue but it is on Raspberry PI. I see bunch of No MTA installed, discarding output message in the log and my program eventually stops running on its own. I believe it is because of CPU spike. It looks like all the answer posted for this question seem to ignore that.
To keep the output, put the command in a script, and pipe stdout and stderr to logger . For example, yourCommand >/dev/null 2>&1 | logger -t mycmd . This will put the output in syslog for safe keeping, and stop the MTA complaints.
For people reading @CivMeierFan’s comment — don’t put the > /dev/null in there 🙂 See Michael Hunter’s answer for more details.
In my case, the message was hinting at a permissions problem with the bash script, but I couldn’t see it until I installed an MTA.
sudo aptitude install postfix I chose «Local» during setup and after running the cron job again:
I was then able to see the error output related to permissions.
perhaps MAILTO=»» in crontab file is enough to stop email and redirect stdout and stderr in command : * * * * * my_command &>> /var/log/cron.log ?
This is an old question but there is an additional answer that is useful in some circumstances.
Pipe the output of your cron command through logger so they end up in the syslog.
It’s slightly easier than installing postfix, and it puts this output into syslog alongside your other logs. This command will capture stdout AND stderr so you won’t see the No MTA installed message and you’ll see all your output in the syslog.
0 3 * * * (cmd1; cmd2) 2>&1 | logger -t mycmd You can view logs with your tag mycmd using:
This answer should be marked as a solution because it exactly solves the question in a modern way with the Syslog service.
As stated in an earlier answer, this happens because your cron jobs are producing output, and then the cron daemon tries to email that output to you. If you don’t want to (or can’t) install an MTA, but you want to see the output, you can redirect the output of the cron job to a log file. Edit your crontab file with
(use sudo if the issue is with root’s crontab) and add >> /some/log/file 2>&1 after every command, like this:
0 3 * * * cmd >> /some/log/file 2>&1
( >> /some/log/file sends the standard output to the named file, appending to any existing content, and 2>&1 sends the error messages to the same place.)
If there are multiple commands on a line, separated by ; , & , && or || , you should do the above for each command, like this:
0 3 * * * cmd1 >> /some/log/file 2>&1; cmd2 >> /some/log/file 2>&1
0 3 * * * (cmd1; cmd2) >> /some/log/file 2>&1
If the command line ends with & , insert the redirection after the command but before the & . If there are commands separated by | (a pipeline), the simple solution is to group them:
0 3 * * * (cmd1 | cmd2) >> /some/log/file 2>&1
but see also the last paragraph, below.
If you want to ignore stdout and capture only stderr, use > /dev/null 2>> /some/log/file instead. Put the log file wherever you want — your home directory, /var/log , or even /tmp if you’re sure you won’t need to keep it.
Then look at the log file after the job runs.
If you find a mangled mess of interlaced messages, it may be that the program(s) are writing stdout and stderr concurrently with poor coordination. In that case, try writing them to separate files with >> /some/log/file1 2>> /some/log/file2 . You may need to do something similar with pipelines:
0 3 * * * cmd1 2>> /some/log/filecmd1err | cmd2 >> /some/log/filecmd2 2>&1
(It’s probably also best to use separate files for commands separated by & .)