In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day. This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too. Maybe it's that I've mostly been administrating BSD machines, and so…
Cronic - A cure for Cron's chronic email problem
31–40 of 47 posts
Re: Cronic - A cure for Cron's chronic email problem
#32I added a simplified version of chronic to moreutils a while back. http://joeyh.name/code/moreutils (also packaged in some major linux distros)
(Disclaimer: I wrote isutf8, which is included in moreutils.)
Re: Cronic - A cure for Cron's chronic email problem
#33In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day. This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too. Maybe it's that I've mostly been administrating BSD machines, and so…
I don't quite think that its a "gnuism" to do that. They generally take a --color option which of course is off by default. They did sometimes put the license everytime, a long time ago, but I don't see that anymore unless you ask the version or help.
echo 1 + 2 | bc
That doesn't produce anything except "3", even with GNU bc.
Re: Cronic - A cure for Cron's chronic email problem
#34Earlier quoted context omitted.
I'm guessing ls which colors; perhaps keychain (very colorful output). I see less of the license stuff these days but no doubt there's a few around.
On Red Hat based systems, ls is an alias for ls --color=auto which means that colors are used only on terminals, not pipes or files.
Re: Cronic - A cure for Cron's chronic email problem
#35In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day. This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too. Maybe it's that I've mostly been administrating BSD machines, and so…
You're bang on. Commands should do what you tell them and say nothing unless something unexpected occurred. (or, if you asked them to say something) Cron isn't broken. It's chatty programs that are broken.
Re: Cronic - A cure for Cron's chronic email problem
#36There are many different cron implementations. Do none of them check exit status?
cron sends a mail if: a) there's output (stdout or stderr) or b) the command exit code isn't 0.
So I really don't understand the post when it says "Now when your cron job fails, you will never know about it.".
Well, if you script fails and still returns 0, your script is broken. If you script outputs stuff when it's not supposed to, it can't run from cron.
Re: Cronic - A cure for Cron's chronic email problem
#37I like how the web page switches to two-column layout if it has enough screen space.
(that alone is worth the article. the "real" content is just misunderstanding of unix i'm afraid)
Re: Cronic - A cure for Cron's chronic email problem
#38Re: Cronic - A cure for Cron's chronic email problem
#39I have this problem, I only want to be emailed upon failure. However, the crontab of the account is shared by several different jobs run by different people, and I don't have control over that. Perhaps I could set the email in the crontab line? * * * * * MAILTO=me@example.com blahscript.sh
blahscript.sh | mail -s "Subject" me@example.com
Re: Cronic - A cure for Cron's chronic email problem
#40I have this problem, I only want to be emailed upon failure. However, the crontab of the account is shared by several different jobs run by different people, and I don't have control over that. Perhaps I could set the email in the crontab line? * * * * * MAILTO=me@example.com blahscript.sh
MAILTO=user1@example.com
* */10 * * * script1
5 * * * * script2
MAILTO=user2@example.com
* * * * * script3
Any output from script1 and 2 will be sent to user1 and any from script3 to user2.