[
https://issues.apache.org/jira/browse/OOZIE-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366468#comment-15366468
]
Rohini Palaniswamy commented on OOZIE-2581:
-------------------------------------------
I was looking at some bytecode generation examples and came across something
that said System.setSecurityManager(null) works. Looking at setSecurityManager0
they do security = s; at the end. Please do recheck if NoOpSecurityManager is
required.
{code}
private static synchronized
void setSecurityManager0(final SecurityManager s) {
SecurityManager sm = getSecurityManager();
if (sm != null) {
// ask the currently installed security manager if we
// can replace it.
sm.checkPermission(new RuntimePermission
("setSecurityManager"));
}
if ((s != null) && (s.getClass().getClassLoader() != null)) {
// New security manager class is not on bootstrap classpath.
// Cause policy to get initialized before we install the new
// security manager, in order to prevent infinite loops when
// trying to initialize the policy (which usually involves
// accessing some security and/or system properties, which in turn
// calls the installed security manager's checkPermission method
// which will loop infinitely if there is a non-system class
// (in this case: the new security manager class) on the stack).
AccessController.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {
s.getClass().getProtectionDomain().implies
(SecurityConstants.ALL_PERMISSION);
return null;
}
});
}
security = s;
}
{code}
> Oozie should reset SecurityManager in finally block
> ---------------------------------------------------
>
> Key: OOZIE-2581
> URL: https://issues.apache.org/jira/browse/OOZIE-2581
> Project: Oozie
> Issue Type: Bug
> Reporter: Satish Subhashrao Saley
> Assignee: Satish Subhashrao Saley
> Attachments: OOZIE-2581-1.patch, OOZIE-2581-2.patch
>
>
> [~jlowe] found lot of lingering oozie launcher AMs which hung around 10 mins
> after successful completion and then jvm killed due to timeout. This happens
> when user code launches non-daemon threads, but mapreduce code does a
> System.exit() to avoid this from happening. Oozie does need the
> LauncherSecurityManager to capture exit codes when user applications do
> System.exit() . But it should reset it back to the originial security manager
> in the finally block so that AM code can proceed as expected in uber mode.
> {code}
> 2016-05-12 12:26:48,514 INFO [Thread-107] org.apache.hadoop.util.ExitUtil:
> Exiting with status 1
> 2016-05-12 12:26:48,514 ERROR [Thread-107]
> org.apache.hadoop.yarn.YarnUncaughtExceptionHandler: Thread
> Thread[Thread-107,5,main] threw an Exception.
> java.lang.SecurityException: Intercepted System.exit(1)
> at
> org.apache.oozie.action.hadoop.LauncherSecurityManager.checkExit(LauncherMapper.java:637)
> at java.lang.Runtime.exit(Runtime.java:107)
> at java.lang.System.exit(System.java:971)
> at org.apache.hadoop.util.ExitUtil.terminate(ExitUtil.java:133)
> at org.apache.hadoop.util.ExitUtil.terminate(ExitUtil.java:170)
> at
> org.apache.hadoop.mapreduce.v2.app.MRAppMaster.exitMRAppMaster(MRAppMaster.java:655)
> at
> org.apache.hadoop.mapreduce.v2.app.MRAppMaster.shutDownJob(MRAppMaster.java:636)
> at
> org.apache.hadoop.mapreduce.v2.app.MRAppMaster$JobFinishEventHandler$1.run(MRAppMaster.java:676)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
