Red Hat Bugzilla – Bug 427866
Yum exits with success even when RPMs cannot be installed
Last modified: 2014-01-21 18:01:17 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:22.214.171.124-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
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
yum exits successfully
yum exits with an error code saying rpm install failed
mock 0.8.19 and up, rawhide mock 0.9.5 and up have the tmpfs plugin.
Created attachment 301756 [details]
running yum update on fedora 8 system
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).
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.
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.
in response to comment #4 by (firstname.lastname@example.org)
* 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.
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.
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...
Panu, applied your patch. Thanks.
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)
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 :)