[Yum] logging and error logging

Troy Dawson dawson at fnal.gov
Wed Jun 12 21:17:56 UTC 2002


seth vidal wrote:
> On Wed, 2002-06-12 at 16:47, Troy Dawson wrote:
> 
>>Michael Stenner wrote:
>>
>>>On Wed, Jun 12, 2002 at 04:22:09PM -0400, seth vidal wrote:
>>>
>>>
>>>>logging will soon be like this:
>>>>
>>>>yum -d 0-1 == nothing, only serious errors that cause an exit
>>>>yum -d 2 == standard output - just informational messages, questions,
>>>>etc
>>>>yum -d 3+ == debug - gratuitous output - increasing as the number
>>>>increases
>>>>
>>>>error logs would always get printed and file (syslog-style) logs would
>>>>also always occur.
>>>>
>>>>the -d # would only affect output and debug logs.
>>>
>>>
>>>Let me see if I get this.
>>>
>>>1) -d # has no effect on what's printed to the log file
>>>2) -d # has no effect on the printing of errors (they're always
>>>   printed to stdout or stderr)
>>>3) -d # only effects HOW MUCH stuff gets printed to stdout/stderr
>>>
>>>Is that right?  If so, it sounds good to me.  
>>>I take it the default is 2 and -d 0 is for things like cron jobs?
>>>Is there a difference between 0 and 1?
>>>
>>>					-Michael
>>
>>What I would like to see is the cronjob output only occurs if something was 
>>updated or installed.  So what if you did
>>
>>yum -d 0 == nothing, only serious errors that cause an exit
>>yum -d 1 == nothing unless something happens, or serious errors that cause an exit
>>
>>Beyond that, I think it looks ok.
> 
> 
> You want the cron job to output something like:
> updated : pkg pkg pkg
> installed: pkg pkg pkg
> erased: pkg pkg pkg
> 
> 
> ?
> 
> I had intended to put that in the log file.
> 
> It would get ugly having an output to cron if you have 100 systems
> updating nightly.
> 
> -sv
> 

It is sortof a tradeoff.  You either get 250 e-mails, or you have to log in 
and look at 250 log files.  (or use a log watcher, when would in turn e-mail 
you, ending up with the first situation)

The trick is to just have it be quiet if it doesn't do anything.  We only put 
things out where an update would get them about once a month normally (unless 
it's an emergency), so we basically get blasted once a month, and the trick is 
to basically look at all your mail, and see which machines *didn't* get updated.

Troy

-- 
__________________________________________________
Troy Dawson  dawson at fnal.gov  (630)840-6468
Fermilab  ComputingDivision/OSS  CSI Group
__________________________________________________




More information about the Yum mailing list