When the Linux crond runs a scheduled job, it typically sends an email to root when the job is complete. It uses the MAILTO variable that is set in /etc/crontab to determine who receives this mail. By default this is set to "root", so the local root account will receive all mail from cron.
There are several ways to stop this behavior. Here we will discuss a few possible solutions.
Change the MAILTO variable to blank
You can edit the /etc/crontab file and change the MAILTO variable to blank. Open /etc/crontab in your favorite editor and change the line that reads:
MAILTO=root
to look like this:
MAILTO=""
This will effectively disable email from crond as it will be configured to have no email address.
This method is not preferred as it would also disable any error messages that you might want to see. If one of the cron jobs exits with an error code, you may never know about it.
Disable all mail for crond
You can simply disable the mail feature in crond. To do this you have to edit the /etc/sysconfig/crond file and change the CRONDARGS (crond arguments) string from this:
CRONDARGS=
To this:
CRONDARGS=-m off
Keep reading for more options.
Redirect Standard Output (STDOUT) and Standard Error (STDERR) to null to suppress output.
By suppressing all output of a script, there will be nothing for crond to send.
Add the following code to the end of any /etc/crontab entry to send stdout and stderr to the bit bucket (/dev/null).
>/dev/null 2>&1
Here is what a script may look like when done correctly:
0 5 * * * /example/script >/dev/null 2>&1
This also has the same drawbacks as above. Since you are redirecting both STDOUT and STDERR, you may never know of any errors that occur.
Of course you have the option of only sending STDOUT to /dev/null, so any errors will still be sent.
0 5 * * * /example/script > /dev/null
This will allow you to still get emails if there are errors. This can also cause problems if your scripts complete their task but don't complete correctly.
To learn more about Standard Stream (stdin, stdout, stderr) see Introduction to Linux IO, Standard Streams, and Redirection.
Configure crond to Send the Script Output to the system log, and disable sending email of output.
You can configure crond to send all output to the system log and disable email (like above). This is probably the a good option because if anything goes wrong with your cron jobs, you have logs of the output and the errors. To do this we have to edit the /etc/sysconfig/crontab file and change the CRONDARGS line to this:
CRONDARGS=-s -m off
Conclusion
All of the above methods work, some are more ideal than others. I figured I would present you with some common options and let you decide what is best for your configuration.
Resources
Leave a Reply Cancel reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
19 Comments
Join Our Newsletter
Categories
- Bash Scripting (17)
- Basic Commands (51)
- Featured (7)
- Just for Fun (5)
- Linux Quick Tips (98)
- Linux Tutorials (65)
- Miscellaneous (15)
- Network Tools (6)
- Reviews (2)
- Security (32)
I am really really not understand
for me cron job message is very serious problem, I cant fix it
Very useful tutorial!
Thank you!
Very nicely put info. Thank you
Thanks, this was just what I needed!
This is what i was looking for. Thank you very much 🙂
I am very useful for read. Thank you.
Thanks! Just what I needed.
Thank! It was that what i'am searching for!
Perfect tutorial. Thanks!
Do you have cron blocking for dummies? I am sick to death of all these cron generated spam messages. I need an EASY way to block on my antiquated earthlink email account. Thanks!!!
Perfect
You need to put quotes around the line in sysconfig. For example:
CRONDARGS="-s -m off"
In RHEL6 you see the problem if you start/stop the crond service, you have the error message `/etc/sysconfig/crond: line 3: -m: command not found`
You'd probably be better off using mail filters on whatever account is receiving the messages. i.e. you might set up a filter that would look for certain types of messages and scan them for certain types of content. If you aren't interested in "everything is functioning" type messages, for example, you could run them through a filter that would check for successful completion and delete the email, perhaps keeping a count or a 'last success' type information. Then only leave messages the deviate from the 'successful'. (see something like procmail or filtermail)
IMHO it is never acceptable to redirect cron job output. That's just an excuse for sloppy programming. Those emails should be used to detect script/program errors. Fix the errors!
If you want to save output for occasional inspection, redirect output from the script (I.E. "exec 1>>/some/logdir/YYYYMMDD_logfile; exec 2>&1"). If you do that, then exit with a non-zero return code only on errors (zero on success), you will only get emails when there is an error and you can peruse the log to see where. Just make sure you age off the logs...
?Thanks!
CRONDARGS="-s -m off" is working on 6 and 7, but not work in 5, how to make it work on 5, I don't want use MAILTO="" to do this, although it's work but like a workaround
Great Info. Thanks!
Exactly what i need!