You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by "Michael Noll (JIRA)" <ji...@apache.org> on 2014/09/05 11:47:28 UTC
[jira] [Created] (STORM-488) storm CLI tool reports zero exit code
on error scenario
Michael Noll created STORM-488:
----------------------------------
Summary: storm CLI tool reports zero exit code on error scenario
Key: STORM-488
URL: https://issues.apache.org/jira/browse/STORM-488
Project: Apache Storm (Incubating)
Issue Type: Bug
Reporter: Michael Noll
Assignee: Michael Noll
Priority: Minor
The {{storm}} CLI tool incorrectly reports a zero exit code ("success") when it should report a non-zero exit code ("error") under the following condition.
h3. How to reproduce
{code}
$STORM_HOME/bin/storm unsupportedCommand
{code}
h3. Actual result (incorrect)
The command above prints the usage help of the {{storm}} CLI tool, which is ok. However, the exit code is 0, indicating success.
{code}
$ /opt/storm/bin/storm unsupportedCommand
Unknown command: [storm unsupportedCommand]
Commands:
activate
classpath
deactivate
dev-zookeeper
drpc
help
jar
kill
list
localconfvalue
logviewer
nimbus
rebalance
remoteconfvalue
repl
shell
supervisor
ui
version
Help:
help
help <command>
Documentation for the storm client can be found at http://storm.incubator.apache.org/documentation/Command-line-client.html
Configs can be overridden using one or more -c flags, e.g. "storm list -c nimbus.host=nimbus.mycompany.com"
$ echo $?
0 << zero exit code, should be non-zero
{code}
The problem of the current behavior is that automated deployment tools such as Puppet or Ansible fail to work correctly because they assume a zero exit code to indicate success.
As a concrete example, imagine you mistype the command to submit a topology jar file to a Storm cluster:
{code}
# Doh, forgot to put the "jar" command between `storm` and `mytopology.jar`!
$ /opt/storm/bin/storm mytopology.jar my.Class
# Correct would be:
# $ /opt/storm/bin/storm jar mytopology.jar my.Class
{code}
In this example, even though the user mistyped the submit command in e.g. an Ansible script, the script would not be able to tell -- the storm CLI tool incorrectly reports that the (wrong) command completed successfully.
h3. Expected result (correct)
Running the storm CLI tool with an unsupported command should return a non-zero exit code to clearly indicate an error condition.
The only remaining question would be: What would be the actual, non-zero exit code?
For example, running the storm CLI tool without any argument returns an exit code of 255:
{code}
$ /opt/storm/bin/storm
...snip...
$ echo $?
255
{code}
Unfortunately, my understanding is that we haven't defined the semantics of non-zero exit codes. Their values are IMHO not deliberately chosen.
For instance, if you run the "storm jar" command these are (some of) its possible exit codes:
{code}
0: success
1:
- topology of same name already exists
`Exception in thread "main" java.lang.RuntimeException: Topology with name `mytopology` already exists on cluster`
- class cannot be found (`storm jar storm-starter.jar storm.starter.IDoNotExistAtAll`)
`Exception in thread "main" java.lang.NoClassDefFoundError: storm/starter/IDoNotExistAtAll` (<<< logged to STDERR)
- incorrect use of command line, e.g. wrong number of command line arguments
{code}
As you can see, we return an exit code of 1 for a variety of error conditions. On the positive side, at least it's clear that there was an error. On the negative side, we cannot tell different error conditions apart because the same exit code is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)