Red Hat Bugzilla – Bug 64744
up2date-2.7.86-7.x.3 - up2date falsely claims action completed fine (?)
Last modified: 2015-01-07 18:56:10 EST
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
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
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...
The total size of the selected packages (24503 kB) exceeds your free disk space
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
I made it raise a OutOfSpaceError in the new code and handle
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
I belive this is fixed in all the current versions.