tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 54601] New: catalina.sh should not modify $JAVA_OPTS to add $LOGGING_MANAGER
Date Fri, 22 Feb 2013 17:24:27 GMT
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: dev@tomcat.apache.org
          Reporter: jglick@apache.org
    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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message