this may actually be an RHN thing depending on who is "silently failing" but the gist of it is a scheduled action to get the glibc bugfix upgrade (errata id 1061, action id 3762584, system id 1000675793) claims the system completed successfully [root@porivoapp01 /root]# rpm -q glibc glibc-2.2.4-19.3 looks like something must have been at least attempted since the relevant headers are still around [root@porivoapp01 /root]# ls /var/spool/up2date/|grep glibc glibc-2.2.4-24.i686.hdr glibc-common-2.2.4-24.i386.hdr glibc-devel-2.2.4-24.i386.hdr but the interesting thing is that the system does have fairly little free disk space for the up2date area [root@porivoapp01 /root]# df -h /var/spool/up2date/ Filesystem Size Used Avail Use% Mounted on /dev/sda5 251M 225M 13M 95% / and, in fact, it doesn't have room to fetch the files [root@porivoapp01 /root]# up2date -u -d Retrieving list of all available packages... [SNIP] The total size of the selected packages (24503 kB) exceeds your free disk space (13510 kB). So, it would appear that something along the chain had up2date sending a success code back even though the upgrade attempt actually failed (in this case, for disk space reasons)
confirmed still a problem with 7.3 I scheduled an action to upgrade the perl-Digest-MD5 errata (eid=1072, aid=3933712, sid=1000784054) after intentionally filling the /var filesystem. Then I manually ran rhn_check: [root@jmm root]# /usr/sbin/rhn_check The total size of the selected packages (17 kB) exceeds your free disk space (0 kB). Came back to RHN Web and it tagged it as the action completing fine but the box still needing the errata (which, of course, it does). I know the mass rewrite/refactor/etc is finishing up, just wanna make sure this is squished during all that :)
Ah, I see the problem now - rhn/actions/packages.py does "ret = batchRun(0, pkgList)" (line 134) and then expects all error conditions to end up throwing exceptions. The "not enough free disk space" condition doesn't (although it looks like it should to conform to the pattern :) throw an exception, it just changes the batchRun return value to 1 instead of 0. The "ret" return value from batchRun is ignored and if the mass-list-o'-exceptions passes (none are caught) then a success code is definitely getting sent back, with a check at line 233 just to see what the description string should be. Making it toss a new exception type makes sense, since currently actions/packages.py establishes the error code to send back to RHN and changing it to actually interpret what batchRun returns would split that logic up since then wrapper.py would dictate some of those codes. I'll be happy to submit a patch to do so, just let me know if a patch for wrapper.py and actions/packages.py against 2.7.86 would be useful or not - just don't wanna do a patch only to have you forced to rewrite it (or realize it's not relevant) for your current code base :)
That looks to be the case, it doesnt throw an excpetion when it should. Thought I had caught all those, no pun intended. Dont worry about a patch, it probabaly wouldnt apply to the current code. I made it raise a OutOfSpaceError in the new code and handle it approriately.
just scanning batchRun, it looks like there are a good chunk of other conditions that could probably use the conversion - the initial up2date.maybeUpdateVersion() could prob. just not catch the RpmError and CommunicationError and just let that go back to batchRun's caller - the return codes from runInteractive/runFromDaemon I'm not sure about, but I'd imagine it'd be ok to convert those internally to all-exceptions-for-failure-cases since the comment notes that runFromDaemon's gonna toss them anyway - the return 1 in "if not selPkgList, but no skippedList's to raise exceptions for" I'm not sure about. The up2date.dryRun's massive list of catches could just re-throw those or just let them go up to the caller Well, you get the point - almost feels like batchRun should just throw exceptions for any kind of failure, the daemon/rhn_check/etc code path converts those exceptions to error codes and appropriate description strings when it calls batchRun and the more interactive mode(s) converts them to stderr output, so the core batchRun stays the same and we let an intermediary caller decide what to do. I know, easier said than done, and the re-write may already take care of all this, just noticed that batchRun would appear (in my admittedly shallow understanding) to have other cases where actions/packages.py could get a failure case back and not know it. The other option is to have actions/packages.py actually check the return code, but I like that less since you end up creating a return-code/error-case mapping anyway (since the error description needs to get sent up to RHN) that's better done just using exceptions so no mapping's needed. Anyway, $.02 and all, just trying to help :) I need to go buy some Japan Air CD's!
I think the current beta code should be handling this properly now, cross-fingers...
I belive this is fixed in all the current versions.