[
https://issues.apache.org/jira/browse/MAPREDUCE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420956#comment-13420956
]
Andy Isaacson commented on MAPREDUCE-2374:
------------------------------------------
bq. I agree that it would be simpler without the -c, but I don't see how this
"avoids the code path that triggers the ETXTBSY."
Currently we are invoking {{bash -c /path/to/script}}. Bash treats the
argument after -c as input to its command processor. The string ends up being
parsed as a command to execute. Bash tries to execve the script, and either
gets ENOEXEC (and then falls back to trying to read the file as a script) or
ETXTBSY (and fails the command). The execve that we sometimes see returning
ETXTBSY is {{execve("/path/to/script", ...)}}.
I'm suggesting we remove the -c, so we would invoke {{bash /path/to/script}}.
According to {{bash(1)}}, "If ... neither the -c nor the -s option have been
supplied, the first argument is assumed to be the name of a file containing
shell commands. ... Bash reads and executes commands from this file, then
exits." The intermittently failing execve is never called, per the
documentation, and I verified with a standalone testcase that the workaround
works correctly. Also it's instructive to observe bash with strace.
bq. We're still calling execve at some point
It's true that we're still calling {{execve("/bin/bash")}} but that is not
relevant to the EXTXBSY failure. Without -c we do not call execve on the shell
script.
> Should not use PrintWriter to write taskjvm.sh
> ----------------------------------------------
>
> Key: MAPREDUCE-2374
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2374
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Affects Versions: 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Fix For: 0.22.1
>
> Attachments: mapreduce-2374-on-20sec.txt, mapreduce-2374.txt,
> mapreduce-2374.txt
>
>
> Our use of PrintWriter in TaskController.writeCommand is unsafe, since that
> class swallows all IO exceptions. We're not currently checking for errors,
> which I'm seeing result in occasional task failures with the message "Text
> file busy" - assumedly because the close() call is failing silently for some
> reason.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
