https://issues.apache.org/bugzilla/show_bug.cgi?id=54601
Bug ID: 54601
Summary: catalina.sh should not modify $JAVA_OPTS to add
$LOGGING_MANAGER
Product: Tomcat 6
Version: 6.0.36
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Native:Integration
Assignee: [email protected]
Reporter: [email protected]
Classification: Unclassified
See https://issues.jenkins-ci.org/browse/JENKINS-7702 and
http://issues.gradle.org/browse/GRADLE-1245 for background. Reproduced in
6.0.36 though reported also in Tomcat 7.
If you set an environment variable $JAVA_OPTS (say, ‘export JAVA_OPTS=-server’)
before running startup.sh, the Catalina JVM will include an environment
variable JAVA_OPTS set to e.g. ‘-server
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager’. (This is
not true if you do _not_ set JAVA_OPTS yourself: catalina.sh will modify a
local shell variable but it does not export it.)
Normally this is harmless. But if the web application happens to fork an
external process which happens to be one of the many Java applications that
interpret $JAVA_OPTS when defined as JVM parameters, and that application uses
java.util.logging at any point, then that application will generally crash
because ClassLoaderLogManager is not in its classpath.
Indeed we did not really want to be passing
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager to the
subprocess. If the user decided to specify some JAVA_OPTS for Tomcat, we should
either pass this var unmodified to the JVM, or not pass it at all.
The fix seems simple enough (patch format upon request): in catalina.sh,
replace
if [ -z "$LOGGING_MANAGER" ]; then
JAVA_OPTS="$JAVA_OPTS
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager"
else
JAVA_OPTS="$JAVA_OPTS $LOGGING_MANAGER"
fi
with
if [ -z "$LOGGING_MANAGER" ]; then
LOGGING_MANAGER=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
fi
CATALINA_JAVA_OPTS="$JAVA_OPTS $LOGGING_MANAGER"
and then replace subsequent references to $JAVA_OPTS with $CATALINA_JAVA_OPTS.
Optionally also
unset JAVA_OPTS
since any JVM options specified for the web server are likely to be
inappropriate for other Java processes it spawns (though
https://github.com/jenkinsci/gradle-plugin/pull/2 suggests otherwise).
The workaround in the web application is to sanitize the JAVA_OPTS environment
variable before forking the subprocess, deleting the ClassLoaderLogManager
configuration if found.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
