Bug 54601 - catalina.sh should not modify $JAVA_OPTS to add $LOGGING_MANAGER
Summary: catalina.sh should not modify $JAVA_OPTS to add $LOGGING_MANAGER
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Native:Integration (show other bugs)
Version: 6.0.36
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-22 17:24 UTC by Jesse Glick
Modified: 2013-12-19 10:45 UTC (History)
0 users



Attachments
2013-02-24_tc6_54601.patch (3.22 KB, patch)
2013-02-23 21:44 UTC, Konstantin Kolinko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2013-02-22 17:24:27 UTC
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.
Comment 1 Konstantin Kolinko 2013-02-23 21:09:26 UTC
You are doing it wrong. The proper way to specify JAVA_OPTS value is to use a $CATALINA_BASE/bin/setenv.sh file.
There is no need to mark the variable for "export" there.

Though I think it is easy to change catalina.sh here to avoid your issues, so I am marking it as an enhancement.
Comment 2 Konstantin Kolinko 2013-02-23 21:44:14 UTC
Created attachment 29985 [details]
2013-02-24_tc6_54601.patch

Patch for Tomcat 6 - backport of r1449406
Comment 3 Konstantin Kolinko 2013-02-23 21:51:56 UTC
Fixed in 7.0 by r1449412 , will be in 7.0.38.
Proposed for 6.0.
Comment 4 Konstantin Kolinko 2013-12-19 10:45:28 UTC
This was fixed in Tomcat 6 in April 2013 by r1476739 and is included in 6.0.37.