Bug 61549

Summary:	RFE: more informative logs in failure cases
Product:	[Retired] Red Hat Linux	Reporter:	James Manning <jmm>
Component:	up2date	Assignee:	Adrian Likins <alikins>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	gafton, mihai.ibanescu, srevivo
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-03-26 00:08:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James Manning 2002-03-21 13:18:31 UTC

2:38am this (03/21/2002) morning, aid=2328200 happened as a failed attempt to 
update a machine with the 2002:024 rpm errata from yesterday.  This action 
failed, but I don't see anything that explains why - exceptions don't seem to 
get logged.  For failed cases, logging seems like it should be mandatory, with 
options for (or made mandatory) emailing root (well, adminAddress, of course :)

[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Mar 21 02:28:23 2002] up2date updating login info
[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Mar 21 02:28:23 2002] up2date logging into up2date server
[Thu Mar 21 02:28:23 2002] up2date successfully retrived authentication token 
from up2date server
[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Mar 21 02:28:23 2002] up2date getAvailablePackageList from network
[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0
[Thu Mar 21 02:28:23 2002] up2date Opening rpmdb in /var/lib/rpm/ with option 0

Comment 1 James Manning 2002-03-21 13:30:31 UTC

well, checking up2date.py the vast majority of Error's have log.log_me so I'm 
not really sure what's going on.  The new rpm packages definitely aren't 
installed, but up2date -u -d runs fine.  What things can cause a failed 
action?  Should RHN be logging more than just that it failed if things outside 
of up2date (more importantly, things up2date can't "notice" are wrong)?

Comment 2 Adrian Likins 2002-03-21 19:29:44 UTC

whats the history for that server on the website show the
status of that action as?

Comment 3 Adrian Likins 2002-03-21 19:30:59 UTC

Currently failed actions and the like dont get logged with much detail
client side, but there should be more info on the website.

Probabaly not a bad idea to log info about failed actions client side
though.

Comment 4 James Manning 2002-03-21 20:35:59 UTC

the history is interesting:

https://rhn.redhat.com/network/system/system_history_event.pxt?sid=1000675937&hid=2348485

The current action status is: Failed
The client picked up this action on 2002-03-21 14:29:20 -0500 (EST)
The client reported completion on execution on 2002-03-21 14:29:24 -0500 (EST)
Client execution returned code 25 (Failed: The package signing key for Red Hat, Inc. is not on the gpg keyring)

Does rhnsd go by up2date's config?  up2date has already upgraded packages on
this machine just fine

porivoweb02:~{1023}# grep gpgKeyRing /etc/sysconfig/rhn/up2date
gpgKeyRing[comment]=The location of the gpg keyring to use for package checking
gpgKeyRing=/etc/sysconfig/rhn/up2date-keyring.gpg

porivoweb02:~{1026}# gpg --list-keys security /etc/sysconfig/rhn/up2date-keyring.gpg
pub  1024D/DB42A60E 1999-09-23 Red Hat, Inc <security>
sub  2048g/961630A2 1999-09-23
porivoweb02:~{1030}# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub  1024D/DB42A60E 1999-09-23 Red Hat, Inc <security>
sub  2048g/961630A2 1999-09-23

I'm pretty lost at this point - is it something dumb I'm missing?

Comment 5 James Manning 2002-03-21 20:41:58 UTC

to "prove" that up2date is fine, here's an up2date -u on the same machine
of one of the packages in that recent rpm errata:

porivoweb02:~{1041}# up2date -u popt

Retrieving list of all available packages...
########################################
########################################

Removing installed packages from list of updates...
########################################

Removing packages with files not specified from list...

Removing packages marked to skip from list...
########################################

Getting headers for available packages...
########################################

Removing packages with files marked to skip from list...
########################################

Testing package set / solving RPM inter-dependencies...
########################################
Retrieving selected packages...
popt-1.6.4-7x.i386.rpm:     ########################## Done.
Preparing...                ########################################### [100%]
   1:popt                   ########################################### [100%]

Comment 6 Adrian Likins 2002-03-21 20:53:33 UTC

yeah, I see the bug.. not exactly sure how to fix it...

more info once I get a chance...

Comment 7 Adrian Likins 2002-03-26 00:07:56 UTC

This bug should be fixed in 2.7.61 or higher. 

I'll try to go back though the code again
and look for places that should be logging that
arent currently, and fix that.

Comment 8 James Manning 2002-05-15 19:28:33 UTC

things look pretty good these days on this front