Bug 74899

Summary: Exit code when RHN is busy is 0 (success)
Product: [Retired] Red Hat Linux Reporter: Jeremy Impson <jdimpson>
Component: up2dateAssignee: Adrian Likins <alikins>
Status: CLOSED DUPLICATE QA Contact: Jay Turner <jturner>
Severity: low Docs Contact:
Priority: low    
Version: 7.3CC: gafton, mihai.ibanescu, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:49:43 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:

Description Jeremy Impson 2002-10-02 17:49:26 UTC
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 19:45:48 UTC

*** This bug has been marked as a duplicate of 67163 ***

Comment 2 Red Hat Bugzilla 2006-02-21 18:49:43 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.