[
https://issues.apache.org/jira/browse/OOZIE-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724912#comment-16724912
]
Andras Salamon commented on OOZIE-3405:
---------------------------------------
{{Possible values of errorCode}} are listed in the
[ErrorCode|[https://github.com/apache/oozie/blob/master/core/src/main/java/org/apache/oozie/ErrorCode.java].]
So we cannot put the exit value of the process here (unless we create 255 new
error codes). We can create one error code for this purpose, and store the
error code in the error message field (with an additional text of course).
Storing the exit value int the {{.error}} file is a good idea. Checking the
existence of the file will work like before, but we can use this info for
filling out the error message.
> SSH action shows empty error Message and Error code
> ---------------------------------------------------
>
> Key: OOZIE-3405
> URL: https://issues.apache.org/jira/browse/OOZIE-3405
> Project: Oozie
> Issue Type: Improvement
> Reporter: Peter Orova
> Assignee: Peter Orova
> Priority: Minor
>
> Currently, when an SSH action fails the only message that is returned is the
> Status. Neither the {{error Message}} nor {{Error code}} fields are filled.
> This makes reporting on the causes of SSH Action failures via Oozie highly
> impractical: the only meaningful bit of information there is on a failed SSH
> Action is the Status.
> The Status is filled based on the presence (or lack of) the {{.error file}}
> that is produced in case the user submitted script returns with any other
> value than 0.
> {noformat}
> SshActionExecutor#getActionStatus
> ...
> String outFile = getRemoteFileName(context, action, "error", false, true);
> String checkErrorCmd = SSH_COMMAND_BASE + action.getTrackerUri() + " ls " +
> outFile;
> int retVal = getReturnValue(checkErrorCmd);
> ...
> {noformat}
>
> User requirement is to provide some more detailed information on the
> success/failure of the user-submitted script. That could be at a minimum the
> return value, optionally the last ~1K of the stderr that is drained. This
> information could then be communicated via {{errorMessage}} and {{ErrorCode}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
