[
https://issues.apache.org/jira/browse/MAPREDUCE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420918#comment-13420918
]
Colin Patrick McCabe commented on MAPREDUCE-2374:
-------------------------------------------------
bq. We can avoid the ETXTBSY by avoiding the execve. If I'm reading launchTask
correctly, the script we're execing isn't even a valid shell script anyways –
it's just a sequence of shell commands, without the leading "#!/bin/sh" header.
By running it bash -c "/path/to/script" we're relying on the ancient pre-Bourne
shell script convention that if execve() fails with ENOEXEC, the shell tries to
interpret the file as a script.
bq. Instead, we can ask bash to directly run the script as a script by running
bash "/path/to/script" leaving out the -c. This avoids the code path that
triggers the ETXTBSY failure and is slightly less reliant on random backwards
compatibility kludges. And it doesn't break if we do have the #!/bin/sh line
since that's just a comment.
That's a very interesting analysis, Andy.
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." We're still calling execve
at some point, and if someone has that FD open for write it will squawk. (All
the other exec flavors are just wrappers around execve and return the same
error codes). Am I missing something?
As you pointed out, it's possible that SELinux is doing something odd.
Shrinivas, can you confirm that seLinux is off during your testing?
Just this command as root and then we will be sure:
{code}
/usr/sbin/setenforce 0
{code}
It will stay in effect until you reboot.
> 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
