[
https://issues.apache.org/jira/browse/STORM-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
P. Taylor Goetz resolved STORM-488.
-----------------------------------
Resolution: Fixed
Fix Version/s: 0.9.3
> 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
> Issue Type: Bug
> Affects Versions: 0.9.3
> Reporter: Michael Noll
> Assignee: Michael Noll
> Priority: Minor
> Labels: newbie
> Fix For: 0.9.3
>
>
> 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 indicates 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)
