Bug 74899 - Exit code when RHN is busy is 0 (success)
Summary: Exit code when RHN is busy is 0 (success)
Status: CLOSED DUPLICATE of bug 67163
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: All Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-02 17:49 UTC by Jeremy Impson
Modified: 2015-01-08 00:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:49:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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:

Steps to Reproduce:
1.Wait until RHN is overloaded (or for other reasons not accepting new update
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.

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