Bug 108171 - Package & config tools should return non-zero exit status upon error
Package & config tools should return non-zero exit status upon error
Status: CLOSED RAWHIDE
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dennis Gregorovic
Jon Orris
:
Depends On:
Blocks: 106597 109665
  Show dependency treegraph
 
Reported: 2003-10-28 06:02 EST by Daniel Berrange
Modified: 2007-04-18 12:58 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-01 14:19:14 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 Daniel Berrange 2003-10-28 06:02:41 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.9 (X11; Linux i686; U;) Gecko/20030314

Description of problem:
When the packaging or config tools encounter an error condition, they print a
message and then simply exit with a 'zero' return status. This makes it
impossible to reliably write scripts that use these tools.

All occurrances of 'return;' in the main() methods should be replaced with
'System.exit(1)'.

 


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


How reproducible:
Always

Steps to Reproduce:
1. Run 'ccm-conf init ccm-core'
2. Run 'echo $?'
3. 
    

Actual Results:  $ ccm-conf init ccm-core
 *** ERROR *** 
Parameter waf.runtime.jdbc_url has the following errors:
        The value must not be null
Parameter waf.web.server has the following errors:
        The value must not be null
Parameter waf.web.host has the following errors:
        The value must not be null
$ echo $?
0


Expected Results:  $ ccm-conf init ccm-core
 *** ERROR *** 
Parameter waf.runtime.jdbc_url has the following errors:
        The value must not be null
Parameter waf.web.server has the following errors:
        The value must not be null
Parameter waf.web.host has the following errors:
        The value must not be null
$ echo $?
1


Additional info:
Comment 1 Daniel Berrange 2003-10-29 09:29:08 EST
Fixed in p4 37482
Comment 2 Daniel Berrange 2003-10-29 11:52:12 EST
I've just learned of the existance of  'MasterTool' which apparently obsoletes
PackageTool & ConfigTool, so this fix will have to be repeated for this new tool.
Comment 3 Richard Li 2003-11-03 15:48:30 EST
done
Comment 4 Daniel Berrange 2003-11-18 12:13:49 EST
This fails even simple testing:

[arturo@staging01 aplaws-camden]$ ccm load ccm-core
 *** Error ***
Parameter waf.runtime.jdbc_url has the following errors:
        The value must not be null
Parameter waf.web.server has the following errors:
        The value must not be null
Parameter waf.admin.email has the following errors:
        The value must not be null
Parameter waf.admin.name.given has the following errors:
        The value must not be null
Parameter waf.admin.name.family has the following errors:
        The value must not be null
Parameter waf.admin.password has the following errors:
        The value must not be null
Parameter waf.admin.password.question has the following errors:
        The value must not be null
Parameter waf.admin.password.answer has the following errors:
        The value must not be null
[arturo@staging01 aplaws-camden]$ 
[arturo@staging01 aplaws-camden]$ echo $?
0
[arturo@staging01 aplaws-camden]$ 
Comment 5 Rafael H. Schloming 2003-11-21 16:56:35 EST
Interestingly enough this passes slightly more complicated testing. If
you invoke MasterTool either directly or using older versions of the
ccm script it does in fact produce the correct exit status. This leads
me to believe that the exit status is not being properly propogated by
either the ccm-run or ccm wrapper scripts. I'd suggest having Dennis
take a look.
Comment 6 Rafael H. Schloming 2003-11-21 17:23:43 EST
After a bit more investigation I think I know what the problem is.
Both ccm-run and ccm use the following perl idiom to invoke subprocesses:

system "foo";
exit $?

This is problematic because $? doesn't actually contain the error code
from the subprocess, it contains some munged value. The lower 8 bits
are set to indicate that the subprocess died from a signal or
something like that, in any case you need to divide $? by 256 in order
to get the actual exit status of the subprocess. Alternatively a
better way might simply be to use the 'exec("foo") or die' idiom.

The reason the exit status is being reported as 0 in this case is
because the subprocess correctly dies with an exit code of 1 and $? is
set to 256, and apparently exit $? simply ignores the high bits
resulting in an exit status of 0.
Comment 7 Dennis Gregorovic 2003-11-22 20:55:22 EST
thanks for tracking this down.  fixes checked in at 38232
Comment 8 Jon Orris 2003-11-26 08:23:36 EST
Still a problem. 
[jorris@localhost cms]$ ccm load ccm-core
 *** Error ***
Parameter waf.admin.email has the following errors:
        The value must not be null
Parameter waf.admin.name.given has the following errors:
        The value must not be null
Parameter waf.admin.name.family has the following errors:
        The value must not be null
Parameter waf.admin.password has the following errors:
        The value must not be null
Parameter waf.admin.password.question has the following errors:
        The value must not be null
Parameter waf.admin.password.answer has the following errors:
        The value must not be null
[jorris@localhost cms]$ echo $?
0

Comment 9 Jon Orris 2003-12-01 11:05:29 EST
Marking QA Fails, just so it's obvious.
Comment 10 Jon Orris 2003-12-01 14:19:14 EST
I can't reproduce, nor can dennis & dan. 
Tis must've been fixed. Perhaps I had an out of date dev environment.

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