View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0014952||CentOS-7||crontabs||public||2018-06-14 16:56||2018-06-14 17:12|
|Target Version||Fixed in Version|
|Summary||0014952: add -n option to crontab(5) to suppress mail when the run was successful|
|Description||Managing the flow of email coming from cron(8) can be a challenge, especially when you manage a lot of machines. A pattern I see in system administration is that either a ton of logic is put in wrappers/scripts to sensibly deal with any output - or even worse all output is zapped with this dreaded pattern:|
* * * * * command_goes_here 2>&1 >/dev/null # piloting blind
In the above example when your cron job fails, you will never know about it. You were depending on cron to backup some files? Screwed! The job has been failing due to filesystem permission errors for weeks - all your files are gone.
There are workarounds for cron(8)'s shortcomings: you can either put logic in your scripts to only output when things went wrong, but then you'll not know about what didn't go wrong: "do x || echo error x".
Another approach is to use wrappers that buffer all output until it is clear what the exit code of the underlaying command was, and then print the output so cron will email. Shims such as cronic or chronic are popular, but not part of base.
To improve the situation I propose to add a simple crontab(5) convenience option called "-n" (mnemonic "No mail if run successful").
With this "no mail if success" option you can do things like:
* * * * * -n cp -rv src/ dest/
With the above example crontab(5) entry you'll only receive a mail from cron(8) if the cp(1) encountered some kind of error. You'll also have in that email up until what point cp(1) actually was able to copy files.
The "-n" option also encourages folks to be liberal with adding trace options to their shell scripts like "set -o errexit -o nounset -o xtrace", and just focus on making sure the script exits with a sensible exit code. This way when there is some kind of problem, you can read the full context from the cron mail and be more productive; and if there is no problem, you won't receive an email, reducing clutter in your inbox.
|Additional Information||This patch was merged into OpenBSD: https://github.com/openbsd/src/commit/14eea8168449751553ba549cb1e8725fe289aeaf - perhaps it can be used as a starting point for a centos version.|
|Tags||No tags attached.|
|CentOS is a rebuild of RHEL. We do not make changes to the RHEL source other than those required to remove their branding and logos etc. To get this implemented you will need to convince Redhat to implement it in RHEL and when/if they do then CentOS will automatically inherit the fix. Since I suspect that this will not happen, I am going to close this bug here.|