Bug 74899 - Exit code when RHN is busy is 0 (success)
Exit code when RHN is busy is 0 (success)
Status: CLOSED DUPLICATE of bug 67163
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.3
All Linux
low Severity low
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-02 13:49 EDT by Jeremy Impson
Modified: 2015-01-07 19:00 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:49:43 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 Jeremy Impson 2002-10-02 13:49:26 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408

Description of problem:
When running up2date, and the Red Hat Network is loaded and refusing new
connections, the up2date program prints out a correct error message and error
code, but it then exit(3)s with a value of 0 to the shell.  According to the
manpage, 0 is a success.  I think it would be better to return another value.  

The manpage says it returns 1 for an error; I suspect it does so when it
encounters a configuration, installation, or runtime error (like failure to
connect).  May I suggest the use of 2 to indicate that while up2date ran
correctly, it did not succeed in updating packages?

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Wait until RHN is overloaded (or for other reasons not accepting new update
connections)
2.Run up2date or up2date-nox
3.Receive a useful error message saying that RHN is not accepting connections...
4...but check the ?$ shell variable, which reports '0'.
	

Expected Results:  I think it would be useful to know (via shell exit code) that
up2date ran, but was refused update access.

Additional info:

This can be worked around by piping the output to another process to check for
the "Error Class" value.
Comment 1 Adrian Likins 2004-08-20 15:45:48 EDT

*** This bug has been marked as a duplicate of 67163 ***
Comment 2 Red Hat Bugzilla 2006-02-21 13:49:43 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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