Bug 64744 - up2date-2.7.86-7.x.3 - up2date falsely claims action completed fine (?)
up2date-2.7.86-7.x.3 - up2date falsely claims action completed fine (?)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-10 09:15 EDT by James Manning
Modified: 2015-01-07 18:56 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-20 18:24:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Manning 2002-05-10 09:15:33 EDT
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)
Comment 1 James Manning 2002-05-15 08:53:31 EDT
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 :)
Comment 2 James Manning 2002-05-15 09:43:14 EDT
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 :)
Comment 3 Adrian Likins 2002-05-15 15:02:44 EDT
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.
Comment 4 James Manning 2002-05-16 10:32:34 EDT
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!
Comment 5 Adrian Likins 2002-08-08 23:20:48 EDT
I think the current beta code should be handling this properly
now, cross-fingers...
Comment 6 Adrian Likins 2003-01-20 18:24:15 EST
I belive this is fixed in all the current versions.

Note You need to log in before you can comment on or make changes to this bug.