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
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)?
whats the history for that server on the website show the status of that action as?
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.
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?
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%]
yeah, I see the bug.. not exactly sure how to fix it... more info once I get a chance...
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.
things look pretty good these days on this front