This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 427866 - Yum exits with success even when RPMs cannot be installed
Yum exits with success even when RPMs cannot be installed
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-07 17:40 EST by Michael E Brown
Modified: 2014-01-21 18:01 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-18 11:36:10 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)
running yum update on fedora 8 system (21.07 KB, text/plain)
2008-04-09 03:02 EDT, Adam Sulmicki
no flags Details
Grab exit code from rpm transaction (841 bytes, patch)
2008-04-11 13:12 EDT, Panu Matilainen
no flags Details | Diff

  None (edit)
Description Michael E Brown 2008-01-07 17:40:53 EST
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:4.4.2.2-7.fc8 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
yum-3.2.8-2.fc8

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
2.
3.
  
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 12:21:33 EDT
YUMBUGDAY
Comment 2 Adam Sulmicki 2008-04-09 03:02:43 EDT
Created attachment 301756 [details]
running yum update on fedora 8 system
Comment 3 Adam Sulmicki 2008-04-09 03:03:58 EDT
I have similar problem. That is the YUM does not properly detect out-of-memory
conditions. 

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 10:28:53 EDT
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 10:39:42 EDT
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 00:07:44 EDT
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 09:15:23 EDT
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 13:12:16 EDT
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 16:34:16 EDT
Panu, applied your patch. Thanks.

Comment 10 Jeremy Katz 2008-04-15 14:17:27 EDT
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 11:36:10 EDT
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.