Bug 108171 - Package & config tools should return non-zero exit status upon error
Summary: Package & config tools should return non-zero exit status upon error
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: other
Version: nightly
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dennis Gregorovic
QA Contact: Jon Orris
URL:
Whiteboard:
Depends On:
Blocks: 106597 109665
TreeView+ depends on / blocked
 
Reported: 2003-10-28 11:02 UTC by Daniel Berrangé
Modified: 2007-04-18 16:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-12-01 19:19:14 UTC
Embargoed:


Attachments (Terms of Use)

Description Daniel Berrangé 2003-10-28 11:02:41 UTC
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 Berrangé 2003-10-29 14:29:08 UTC
Fixed in p4 37482

Comment 2 Daniel Berrangé 2003-10-29 16:52:12 UTC
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 20:48:30 UTC
done

Comment 4 Daniel Berrangé 2003-11-18 17:13:49 UTC
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 21:56:35 UTC
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 22:23:43 UTC
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-23 01:55:22 UTC
thanks for tracking this down.  fixes checked in at 38232

Comment 8 Jon Orris 2003-11-26 13:23:36 UTC
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 16:05:29 UTC
Marking QA Fails, just so it's obvious.

Comment 10 Jon Orris 2003-12-01 19:19:14 UTC
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.