Bug 427866 - Yum exits with success even when RPMs cannot be installed
Summary: Yum exits with success even when RPMs cannot be installed
Alias: None
Product: Fedora
Classification: Fedora
Component: yum   
(Show other bugs)
Version: 8
Hardware: All Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2008-01-07 22:40 UTC by Michael E Brown
Modified: 2014-01-21 23:01 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-18 15:36:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
running yum update on fedora 8 system (21.07 KB, text/plain)
2008-04-09 07:02 UTC, Adam Sulmicki
no flags Details
Grab exit code from rpm transaction (841 bytes, patch)
2008-04-11 17:12 UTC, Panu Matilainen
no flags Details | Diff

Description Michael E Brown 2008-01-07 22:40:53 UTC
Description of problem:

Found when using new tmpfs plugin for mock. If the machine runs out of RAM while
installing the buildroot, you get many messages like the following in the root log: 

DEBUG util.py:261:  Error unpacking rpm package gzip - 1.3.12-4.fc8.x86_64
DEBUG util.py:261:  error: unpacking of archive failed on file
/bin/gzip;4782907c: cpio: write failed - No space left on device

But yum continues and finally exits with 0 return code. The last yum message is:

DEBUG util.py:261:  Installed: gcc-c++.x86_64 0:4.1.2-33 make.x86_64
1:3.81-10.fc8 redhat-rpm-config.noarch 0:9.0.1-1.fc8 rpm-build.x86_64
0: tar.x86_64 2:1.17-4.fc8 unzip.x86_64 0:5.52-5.fc8
DEBUG util.py:261:  Dependency Installed: ConsoleKit-libs.x86_64 0:0.2.3-1.fc8
MAKEDEV.x86_64 0:3.23-1.2 audit-libs.x86_64 0:1.6.2-4.fc8 basesystem.noarch
0:8.1  --- cut ---

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

$ rpm -q yum

How reproducible:

Run mock and enable the tmpfs plugin on a system with <512MB RAM. Mock exits
with the error, "Could not find useradd in chroot..." instead of with a yum error.

This could cause failed builds if there is enough RAM to install most of the
buildroot but certain packages are left out.

Steps to Reproduce:
1. mock -r fedora-8-x86_64 --enable-plugin=tmpfs --rebuild SAMPLE.src.rpm
Actual results:
  yum exits successfully

Expected results:
  yum exits with an error code saying rpm install failed

Additional info:
  mock 0.8.19 and up, rawhide mock 0.9.5 and up have the tmpfs plugin.

Comment 1 Seth Vidal 2008-03-12 16:21:33 UTC

Comment 2 Adam Sulmicki 2008-04-09 07:02:43 UTC
Created attachment 301756 [details]
running yum update on fedora 8 system

Comment 3 Adam Sulmicki 2008-04-09 07:03:58 UTC
I have similar problem. That is the YUM does not properly detect out-of-memory

Result of this are that : 

* number of packages is left in indeterminate state, This as made worse that yum
won't abort after first out of memory experience, but it keeps continuing.

* yum has failed to detect that some packages weren't installed due to above OOM.

* yum removed not installed rpm's from system

I have attached output the failed yum run (interestingly running dmesg does not
show kernel's OOM killer kicking in).

Comment 4 Panu Matilainen 2008-04-09 14:28:53 UTC
The OOM happens deep inside rpm, yum doesn't get a chance to do anything about it.  

Aborting the transaction on problems is basically just as bad as continuing,
you'll end up with an inconsistent system anyhow.

Comment 5 Michael E Brown 2008-04-09 14:39:42 UTC
I'd like to take this opportunity to say that this defect was originally
reported in context of using it with 'mock', which is a chroot building tool.
The problem reported is that yum was exiting with a '0' return code in cases
where the underlying RPM failed to install. The comments by Adam (#2, #3) are
just another manifestation of that same bug.

In the case where 'mock' is running yum, then the comment from the second
paragraph of #4 above does not apply, because in this case 'mock' will detect
the situation and properly report back to the user what is going on (and
possibly clean up the failed chroot as well.) Basically we dont care that the
transaction aborted and the 'system' is inconsistent because it is a chroot. I
just need a way to detect this situation.

Comment 6 Adam Sulmicki 2008-04-10 04:07:44 UTC
in response to comment #4 by (pmatilai@redhat.com)

* rpm should return error (fatal/oom?) error, and yum should detect it and abort.

* it is far better to have one package in inconsistent state than 20 packages in
inconsistent state, so aborting yum is a win.

Comment 7 Seth Vidal 2008-04-10 13:15:23 UTC
If the one package is glibc then having it in an inconsistent state is doom.

If the one package is something your X server requires to run, you're done.

It really doesn't matter.

Comment 8 Panu Matilainen 2008-04-11 17:12:16 UTC
Created attachment 302148 [details]
Grab exit code from rpm transaction

The attached patch makes yum emit a warning if some errors occurred during the
transaction. The exit codes from ts.run() of current bindings are "creative"
but at least yum will warn you instead of happily saying "Complete!" if
something went belly-up while in transaction. Feel free to tune the exact
message to your liking...

Comment 9 Seth Vidal 2008-04-14 20:34:16 UTC
Panu, applied your patch. Thanks.

Comment 10 Jeremy Katz 2008-04-15 18:17:27 UTC
Uhhh, this patch (and a couple of others that have been committed in this area)
breaks the expectations of API users including anaconda in huge ways.

Now we get an exception in the case of there being scriptlet errors.  We
previously only got an exception in the case of fatal transaction errors.  Which
means that anaconda says "your install failed" when really it's just that a
scriptlet failed.  And with the change to just raising a string rather than a
list of tuples, I can't even say "well, this is an error I don't care about"
(although even that is ugly as it's still a pretty major semantic shift for
every API caller)

Comment 11 Seth Vidal 2008-04-18 15:36:10 UTC
Okay so here's is what I checked in:
 - exit appropriately if something died fatally in the transaction
 - emit a warning if there were scriptlet errors
Panu, your patch made sense but it inconveniently broke anaconda :)

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