Bug 1120255

Summary: Wrong JAVA_HOME/JRE_HOME auto-detection on RHEL
Product: [JBoss] JBoss Enterprise Web Server 2 Reporter: Michal Haško <mhasko>
Component: tomcat6, tomcat7Assignee: Coty Sutherland <csutherl>
Status: CLOSED DEFERRED QA Contact: Michal Karm Babacek <mbabacek>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 2.1.0CC: jdoyle, pslavice, rsvoboda, smumford
Target Milestone: CR01   
Target Release: 2.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Known Issue
Doc Text:
When using JBoss Enterprise Web Server 3.0 with Red Hat Enterprise Linux, installing Java from RPM results in the JAVA_HOME or JRE_HOME variable unexpectedly not being set. The tomcat start up scripts are able to automatically detect these variables, but when Java is installed from RPMs, <command>which java</command> translated to <filename class="directory">/usr/bin/java</filename>, which is a symbolic link maintained by alternatives. As a result, the <literal>JAVA_HOME</literal> and <literal>JRE_HOME</literal> variables are incorrectly set to <filename class="directory">/usr</filename>. <literal>JRE_HOME</literal> and <literal>JAVA_HOME</literal> using this incorrect value has not historically resulted in any problems for users (based on bug reports and user support), but a problem manifests when using the <filename>daemon.sh</filename> script: <screen> # ./daemon.sh start' Cannot find any VM in Java Home /usr # grep 'Cannot find any VM in Java Home' ./* Binary file ./jsvc matches</screen> The <filename>jsvc</filename> is only used in <filename>daemon.sh</filename>, therefore this problem does not manifest when tomcat is started using the <filename>startup.sh</filename> or <filename>catalina.sh</filename> scripts but does appear when using <filename>daemon.sh</filename>. This is a known issue in JBoss Enterprise Web Server 3.0 and there is currently no workaround for this problem.
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-09 14:49:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michal Haško 2014-07-16 14:39:36 UTC
Description of problem:
On RHEL, when java is installed from rpm, the JAVA_HOME or JRE_HOME environment variables are not set. Luckily, the tomcat startup scripts are able to auto-detect them by:

  daemon.sh:96:
    JAVA_BIN="`which java 2>/dev/null || type java 2>&1`"
    test -x "$JAVA_BIN" && JAVA_HOME="`dirname $JAVA_BIN`"
    test ".$JAVA_HOME" != . && JAVA_HOME=`cd "$JAVA_HOME/.." >/dev/null; pwd`

  setclasspath.sh:35:
    JAVA_PATH=`which java 2>/dev/null`
    if [ "x$JAVA_PATH" != "x" ]; then
      JAVA_PATH=`dirname $JAVA_PATH 2>/dev/null`
      JRE_HOME=`dirname $JAVA_PATH 2>/dev/null`
    fi

The problem is that when java is installed from rpm, `which java` evaluates to '/usr/bin/java', which is a symlink maintained by alternatives.  The code snippets above will evaluate to JAVA_HOME and JRE_HOME being set to '/usr'.

Having JRE_HOME set to '/usr' doesn't seem to cause problems for tomcat, because I verified that this issues has been present at least since EWS-2.0.1 and there haven't been any issues with tomcat suggesting a bug with JAVA_HOME/JRE_HOME.

The problem manifests itself when running the daemon.sh script:

    # ./daemon.sh start'
    Cannot find any VM in Java Home /usr

    # grep 'Cannot find any VM in Java Home' ./*
    Binary file ./jsvc matches

jsvc is only used in daemon.sh, therefore this problem was not seen when starting tomcat using startup.sh or catalina.sh.

I think a good fallback for JAVA_HOME and JRE_HOME is '/usr/lib/jvm/java' and '/usr/lib/jvm/jre' respectively.


Version-Release number of selected component (if applicable):
EWS-2.0.1
EWS-2.1.0-ER4


How reproducible:
100%


Steps to Reproduce:
1. cd tomcat7/bin
2. ./daemon.sh start


Actual results:
Cannot find any VM in Java Home /usr

Comment 3 Coty Sutherland 2017-08-09 14:49:23 UTC
See JWS-797