Bug 463999 - Rpm can "delete old versions" without having "installed new versions"
Rpm can "delete old versions" without having "installed new versions"
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
All Linux
medium Severity high
: beta
: ---
Assigned To: Panu Matilainen
Depends On:
  Show dependency treegraph
Reported: 2008-09-25 15:52 EDT by Denise Dumas
Modified: 2009-01-20 15:49 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 15:49:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0079 normal SHIPPED_LIVE rpm bug fix update 2009-01-20 11:04:16 EST

  None (edit)
Description Denise Dumas 2008-09-25 15:52:06 EDT
Description of problem:
The problem is outlined in this recent thread on fedora-devel:


...but basically if an exception occurs in the yum RPMTransaction callback,
then rpm can go insane and run the "delete old versions" part of the updates
without having run the "install new versions". An exception can be generated on
I/O if the ssh connection dies of the person running the yum update command.
 So if you are updating glibc over ssh and the network goes away, rpm can
remove the C library and thus. kill the machine.

We have a piece of python code which ends up calling code in librpm. The librpm code calls back to the python code for certain things, such as taking care of opening file descriptors for packages that we're about to install. So far so good, nothing too special here.

But... the unthinkable happens and there's a bug in the callback code - say it returns the string "fool you!" instead of being a good boy and handing us a file descriptor integer. Rpm notices this, gets sulky (quietly discarding the exception) and simply doesn't perform the callback to python anymore on subsequent events. Now, remember that the callback is supposed to, among other things, hand opened file descriptors back to rpm for performing package installations. If the callback doesn't perform that, nothing will and there will be nothing to install. Oops. But rpm goes on a zombie rampage:

    "I shall finish my dirty deed and no dead python is going to stop me!"

And this is where the "always been a hack, now mostly broken" part strikes. If that part functioned correctly, nothing *too* bad would happen. As it is, rpm can end up erasing half the system in the worst case. Fixing the "install failed so don't erase" algorithm is one thing, and not entirely trivial. But in this case we never ever should've gotten that far, because the process should've terminated a long, long time ago.

The good news: getting exceptions in python callback(s) just dump a traceback and abort is trivial to do.

See also yum BZ 463447 for the associated yum fix for this issue. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 9 errata-xmlrpc 2009-01-20 15:49:12 EST
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.


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