Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!mit-eddie!uw-beaver!rice!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: cron in sunos 4.0
Keywords: Software
Message-ID: <1174@auspex.UUCP>
Date: 4 Apr 89 08:04:41 GMT
References: <8903031858.AA23450@emoryu1.cc.emory.edu>
Sender: usenet@rice.edu
Organization: Auspex Systems, Santa Clara
Lines: 56
Approved: Sun-Spots@rice.edu
Original-Date: 17 Mar 89 21:00:04 GMT
X-Sun-Spots-Digest: Volume 7, Issue 223, message 1 of 15

>To take a potshot, what ever happened to the Unix philosophy that said
>programs should NEVER be needlessly chatty?

It was greatly misapplied by people with bogus notions of "needlessly"
and, in that form, found wanting and discarded.

>Is there anyone else out there who is sick of getting umpteen messages a
>day from cron?  Is there any way to shut the d*mn program up?

"cron" probably isn't what's being "chatty".  The jobs you're *running*
with "cron" are probably what are being chatty; "cron" is just dutifully
and correctly mailing you all the output from those jobs.  The way to shut
those jobs up is to first ask "why is it telling me this stuff?":

	If it's reporting an error - i.e., a condition that you don't
	expect, and don't want to happen - the way to silence it should
	be quite obvious....

	If it's reporting an unusual condition that isn't an error, or
	at least not a fatal one, ask yourself "do I really care about
	this condition?"  If not, then modify the job not to report
	that; note that this probably renders it nicer even when *not*
	run from "cron".  If so, it's not as "needlessly chatty" as you
	think....

	If it's reporting a normal condition, then it's probably
	needlessly chatty; fix the job not to be so chatty.  If the
	report is of interest when the job is run "interactively", but
	not from "cron" or "at", redirect the output of the job to
	"/dev/null".

The problem may not be with the job as a whole, but with one or more of
the programs run by the job, in which case apply the above to those
programs.  Consider "mailq" (or, for those of you on systems such as SunOS
that don't have "mailq" as a symbolic link to "sendmail",
"/usr/lib/sendmail -bp"), which insists on saying "Mail queue is empty"
when the queue is empty, instead of just exiting.  I run this in a "cron"
job, since every so often a mail job seems to get locked without getting
completed.  I have to pipe "sendmail"s output through "egrep" to filter
out the "Mail queue is empty" message, so that I don't get a mail message
every night indicating that there's no stuck jobs.  The problem here is
*not* with "cron"; it's with "sendmail". 

I am quite grateful that "cron" now reports output from jobs; without
that, a job can fail with no direct notification of its failure.  You then
find that something funny is going on, and after some poking around
discover that e.g. some database that was *supposed* to be updated nightly
hasn't been updated in the past N days.  You *still* don't have a copy of
the complaint from the updating job, so you either have to run it
manually, or do some *more* poking around to find out what the problem
is....  (This, of course, presumes that the updating program(s) were not
*also* written with the notion that "silence is golden", so that if you
actually *do* see their output you can find out not only when they've
failed, but *why* they failed.)

Silence is *not* always golden; often, it's just pyrite.