Vinod Kumar Vavilapalli commented on YARN-2934:

bq. Yes it's related, but not exclusive to AM (try 
-Dmapreduce.map.env=JAVA_HOME=/no/jvm/here). It's just more severe with AM.
Agreed. I was just saying that we can do what we did for AMs.

bq. The pointer to the tracking page can be of little value for a busy cluster. 
The RMApp is likely to age out by the time the user gets to look at it, and 
there is no JHS entry because the AM crashed.
Good point, I missed this one. Given this, even the tailed stderr is not useful 
in such a situation. If the app-page ages out, where will the user see this 
additional diagnostic message that we tail out of logs?

bq. It would be better to mention the nodeAddress as well, in addition to 
containerId to be used with 'yarn logs' 
This can be done in the additional message (like for AM) instead of cat/tail of 

I guess the options are (1) Diagnostic message with links and reference to the 
right logs saying something happened or (2) Diagnostic message itself 
containing the tail of the log (which may or may not really determine the error 
message). I think (1) is a must, (2) is a good to have.

> Improve handling of container's stderr 
> ---------------------------------------
>                 Key: YARN-2934
>                 URL: https://issues.apache.org/jira/browse/YARN-2934
>             Project: Hadoop YARN
>          Issue Type: Improvement
>            Reporter: Gera Shegalov
>            Assignee: Naganarasimha G R
>            Priority: Critical
> Most YARN applications redirect stderr to some file. That's why when 
> container launch fails with {{ExitCodeException}} the message is empty.

This message was sent by Atlassian JIRA

Reply via email to