skip@decwrl.dec.com (Brian Schipper) (04/04/89)
arnold@emoryu2.cc.emory.edu (Arnold D. Robbins) writes: >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? Just pipe the output from your cron jobs to /dev/null, like this: 0 15 * * * /etc/dosomething > /dev/null -- Internet: skip@claris.com Applelink: SCHIPPER1 UUCP: {ames,apple,decwrl,sun}!claris!skip Phone: 415-960-2618
scs@lokkur.uucp (Steve Simmons) (04/04/89)
arnold@emoryu2.cc.emory.edu (Arnold D. Robbins) writes: >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? Walking very gently, without intending to flame... My experience with the new cron seems to be radically different from yours. The new cron generates error messages back to the user when errors occur, rather than simply pitching them or having the cron process silently fail. Yes, when we converted to 4.0 I got beaucoup (or however you spell it) messages, but every single one was an indicator of an error I'd not previously been picking up. Sure, some of them were trivial. But all of them were messages that would have been printed in an interactive run. Since cron is (for me) primarily a system administrative tool, I considered it quite important that those error messages be reported, not trashed. It didn't take long at all to go thru my cron scripts and fix things up. In fact, it uncovered a fair number of latent and not-so-latent bugs in the scripts. In addition, whenever something changed in the system that broke the cron scripts I found out immediately -- not six months later when log files overflowed or accounts weren't purged. Don't like the performance? Fix the scripts, or trap stderr to /dev/null. Don't flame something that's really a major improvement. As for public software: hey, why not pick up Paul Vixies PD cron? He just released it for beta test. Of course, you'll have to take out the automatic error notification features. But it runs on 4.3 BSD, so should go on a Sun with little problem. + Steve Simmons, Inland Sea Software, Ltd. scs@lokkur.dexter.mi.us + | 9353 Hidden Lake, Dexter, MI. 48130 313-426-8981 |
guy@uunet.uu.net (Guy Harris) (04/04/89)
>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.
arisco%cadillac.cad.mcc.com@mcc.com (John Arisco) (04/04/89)
> Is there any way to shut the d*mn program up ? > To take a potshot, what ever happened to the Unix philosophy that > said programs should NEVER be needlessly chatty? Actually, this is a rather nice feature of 4.0. It does not make sense for a cron job to produce any output, so 4.0 allows for this to be handled as a special case, and mails the output to you. To shut the noise up, just make sure that nothing in your crontab produces any output. We found the big offender to be "find" with a path argument of /. Note that /usr/lib/find/updatedb does one of these. Just prepend " >/dev/null 2>&1" to these lines in your crontab. I did not like 4.0 cron at first, but now I really appreciate it. I especially like the idea of private crontabs for each user and the crontab(1) command to manipulate them. John Arisco, MCC CAD Program | ARPA: arisco@mcc.com | Phone: [512] 338-3576 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!arisco
zjat02@uunet.uu.net (Jon A. Tankersley) (04/19/89)
No, I don't mind it that much, but what I think is interesting is the difference in the messages. I installed the 4.0.1 automount patch and now get messages every night about can't find mount point for /net. Trouble is the sun3 systems print the command while the sun4 systems don't (or vice-versa). Got a problem logged on that one. Simple solution is to place >/dev/null 2>&1 on the end of the command. -tank- #include <std/disclaimer.h> /* nobody knows the trouble I .... */