Bug 427866
| Summary: | Yum exits with success even when RPMs cannot be installed | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael E Brown <michael_e_brown> | ||||||
| Component: | yum | Assignee: | Seth Vidal <skvidal> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 8 | CC: | ffesti, james.antill, katzj, pmatilai, sulmicki, tim.lauridsen | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-04-18 15:36:10 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Michael E Brown
2008-01-07 22:40:53 UTC
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) * 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 :) |