Hide Forgot
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.
YUMBUGDAY
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 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).
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 (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.
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 :)