Bug 448245 - updates failing on python bug
updates failing on python bug
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum-rhn-plugin (Show other bugs)
5.2
i386 Linux
high Severity medium
: rc
: ---
Assigned To: Pradeep Kilambi
: ZStream
Depends On:
Blocks: 497780
  Show dependency treegraph
 
Reported: 2008-05-24 18:07 EDT by Darren
Modified: 2013-01-10 05:24 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
previously, if yum itself was updated during an update transaction, the version of yum running in memory might attempt to read a yum.conf file that was updated for the new version of yum. If the new yum.conf file were incompatible with the old version of yum, yum would crash and the transaction would fail. Now, before running the transaction, yum creates a YumBase object to hold the actions and associated parameters that it will need during the transaction. By referring to this object, yum does not need to obtain configuration information during the transaction, and therefore avoids any incompatibility introduced by a change in the yum.conf file.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:22:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Darren 2008-05-24 18:07:28 EDT
Description of problem:
RHN reports hundreds of updates failing. The error is: Client execution returned
"Fatal error in Python code occured [[6]]" (code -1)
 
Checking the up2date log shows hundreds of the following messages:
[Wed May 21 18:05:31 2008] up2date updating login info
[Wed May 21 18:05:31 2008] up2date logging into up2date server
[Wed May 21 18:05:32 2008] up2date successfully retrieved authentication token
from up2date server
[Wed May 21 18:05:33 2008] up2date
Traceback (most recent call last):
  File "/usr/sbin/rhn_check", line 273, in __run_action
    (status, message, data) = CheckCli.__do_call(method, params)
  File "/usr/sbin/rhn_check", line 266, in __do_call
    retval = method(*params)
  File "/usr/share/rhn/actions/errata.py", line 63, in update
    return packages.update(packagelist)
  File "/usr/share/rhn/actions/packages.py", line 223, in update
    return runTransaction(transaction_data)
  File "/usr/share/rhn/actions/packages.py", line 256, in runTransaction
    return _run_yum_action(command)
  File "/usr/share/rhn/actions/packages.py", line 278, in _run_yum_action
    yum_base = YumAction()
  File "/usr/share/rhn/actions/packages.py", line 51, in __init__
    self.doConfigSetup()
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 125, in
doConfigSetup
    plugins and logging.
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 602, in readMainConfig
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 371, in populate
    def parse(self, s):
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 75, in __set__
    @param value: The value to set the option to.
exceptions.ValueError: Error parsing '1h': invalid integer value
 
I tried updating manually with yum update
Several hundred packages ~200 are identified for update. They all download and
install apparently successfully. Running yum update again says no packages to be
updated.

Version-Release number of selected component (if applicable):
yum 3.2.8
Python 2.4.3

How reproducible:
hundreds of packages not installed.

Steps to Reproduce:
1. Unknown. Updates failing through rhn
2.
3.
  
Actual results:
updates fail. python errors

Expected results:
updates successfully installed.

Additional info:
Comment 2 RHEL Product and Program Management 2008-06-04 09:53:50 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 James Antill 2008-06-04 10:15:47 EDT
 This looks like an RHN problem.
 From what I can see, this is what is happening:

1. rhnsd/rhn_check loads yum code into memory.
2. rhn_check updates yum
3. updated yum gets new config. file
4. old yum code from memory is run
5. old yum code blows up due to incompatible config. file

...I'm not sure what I can do on the yum side, if I'd have known I could have
removed things from the default config. file ... and that might have at least
lessened the impact.

 Does the above sound likely to be the problem?
 How high an impact is this?
   Will rhnsd/rhn_check ever restart itself?

 I could do a yum errata with a "compatible" config. file, but I can give zero
guarantee that you can run the old yum code after updating to it ... the only
sane thing to do is to stop using the old yum code after it's been updated.
Comment 4 Uwe Beck 2008-06-04 15:11:26 EDT
I see the same problem on my systems. If you reschedule the failing updates then
you will have a very broken system at the end with duplicate rpm versions ....

If you use up2date for the failing updates all updates will installed correct
(also if your system have only "unsupported" 256 MB RAM). 

Please remember what the up2date tool in RHEL2.1, RHEL3 and RHEL4 do if there
is a up2date update:

1. interactiv up2date
- ask you if you want install the up2date update first
- restart up2date at the end of update

2. queued over RHN
- install new up2date, restart up2date and send the result of update to RHN
- next job from RHN runs with the new up2date code

The RHEL5.2 yum version is not compatible with the RHEL5.x yum versions before.
I think that yum should be able to restart itself if there is a own code update.
At this time you can only do this with a own script with disables rhnsd and
yum-updatesd on the system.

RHEL5.2 yum version have also problems with yum-updatesd and also kickstart
installation which use the repo parameter do not longer work correct.

Please see also IT_181697, IT_182034, IT_182370, IT_182720 ...
Comment 5 Darren 2008-06-04 19:14:34 EDT
Since running yum update and rebooting the systems the problem seems to have
resolved itself. The up2date log now reflects packages being updated without the
python error for the last 4 days. So perhaps this was an bug in a previous rhn
related package that has now been fixed? I will post back if the error recurs.
Comment 20 Arunraj B 2008-10-10 08:48:47 EDT
Currently using RHEL5 version and planed to upgrade latest.

whether any new upcoming release is awaiting from redhat server edition.
Comment 31 Chris Ward 2009-07-03 14:03:05 EDT
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.
Comment 35 Ruediger Landmann 2009-08-27 21:50:29 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
previously, if yum itself was updated during an update transaction, the 
version of yum running in memory might attempt to read a yum.conf file
that was updated for the new version of yum. If the new yum.conf file 
were incompatible with the old version of yum, yum would crash and 
the transaction would fail. Now, before running the transaction, yum 
creates a YumBase object to hold the actions and associated  parameters 
that it will need during the transaction. By referring to this 
object, yum does not need to obtain configuration information during the 
transaction, and therefore avoids any incompatibility introduced by a 
change in the yum.conf file.
Comment 36 errata-xmlrpc 2009-09-02 07:22:15 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1355.html

Note You need to log in before you can comment on or make changes to this bug.