If you catch it in the act, I bet its going to be some kind of deadlock between the jvm's shell reaper thread, the main process, and the new process doing the parseExecResult. There's too many threads accessing highly synchronized readers/streams.
I'm uneasy about this patch in general. Changing the semantics of anything in hadoop-common is fraught with peril. Subclasses are not expecting their parseExecResult to be run in a thread which may introduce subtle errors including but not limited to synchronization/volatility issues. Or if method uses thread locals but now it's in a different thread, etc.
While interrupting a thread in a shell command would be nice, I think the more general requirement for yarn is that processes are not left running. It's probably a safer assumption that no hadoop service wants lingering processes. Perhaps create a set of all running shell instances. A shutdown hook could call destroy() on all the instances still registered.