Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-12519

Bundled Elasticsearch unable to start unless JAVA_HOME is declared

XMLWordPrintable

      Issue Summary

      After a recent update to Elasticsearch 7 in Bitbucket 7.1.0, the default elasticsearch-env file within the directory $BITBUCKET_INSTALL/elasticsearch/bin has changed, making it so that the bundled Elasticsearch instance will not start up unless the environment variable JAVA_HOME has been set. This is because Elasticsearch's new backup Java location, if JAVA_HOME is not detected, is a bundled JDK that isn't actually present at $ES_HOME/jdk/bin/java.

      Steps to Reproduce

      1. Install or upgrade to Bitbucket 7.1+
      2. Ensure that the JAVA_HOME environment variable has not been set
      3. Attempt to start up Bitbucket and Elasticsearch by manually executing the file $BITBUCKET_INSTALL/bin/start-bitbucket.sh

      Expected Results

      Both Bitbucket and Elasticsearch use the bundled JRE located at $BITBUCKET_INSTALL/jre

      Actual Results

      The startup script successfully launches Bitbucket, but on attempting to launch Elasticsearch the following error is thrown in the console:

      could not find java in bundled jdk at /opt/app/bitbucket-7.4.0/elasticsearch/jdk/bin/java
There was a problem starting bundled Elasticsearch

      In previous versions of Elasticsearch, on not detecting JAVA_HOME it instead used the command which java to find an alternative Java location. However, in the later versions of this elasticsearch-env file the logic there uses a static location based on the $ES_HOME:

      # now set the path to java
if [ ! -z "$JAVA_HOME" ]; then
  JAVA="$JAVA_HOME/bin/java"
  JAVA_TYPE="JAVA_HOME"
else
  if [ "$(uname -s)" = "Darwin" ]; then
    # macOS has a different structure
    JAVA="$ES_HOME/jdk.app/Contents/Home/bin/java"
  else
    JAVA="$ES_HOME/jdk/bin/java"
  fi
  JAVA_TYPE="bundled jdk"
fi

      Workaround

      Set the environment variable JAVA_HOME to point to either the standard Bitbucket bundled JRE, or the Java home of a supported Java version.

      Alternatively, it's also possible to modify the logic in the file $BITBUCKET_INSTALL/elasticsearch/bin/elasticsearch-env to use a different/correct Java location. However, it's important to note that any changes to this file will be overwritten on performing an upgrade of Bitbucket and these changes will then need to be reapplied.

          Form Name

            [BSERV-12519] Bundled Elasticsearch unable to start unless JAVA_HOME is declared

            Brent P added a comment -

            This and BSERV-12267 have the same cause so we're merging this to BSERV-12267.

            Brent P added a comment - This and BSERV-12267 have the same cause so we're merging this to BSERV-12267 .

            Mateusz Pelczarski added a comment -

            I had this issue with version 7.6.0. Atlassian is providing jre with install_method but not with upgrade/archive one... Main problem is that both instances Bitbucket and ElasticSearch can't use one JAVA_HOME even when we edit /etc/profile only one instance will start. If we check set-jre-home.sh after install_method its pointing directly to atlassian_install/jre/ directory where java is stored. 

            To point to correct java version we want to use for elasticsearch the best way is to edit code in atlassian_install/elasticsearch/bin/elasticsearch-env

             

            I just added this two lines:

             38 JAVA="java_directory"
 39 JAVA_TYPE="JAVA_HOME"

            and comment this lines:

            #if [ ! -z "$JAVA_HOME" ]; then
#  JAVA="$JAVA_HOME/bin/java"
#  JAVA_TYPE="JAVA_HOME"
#else
#  if [ "$(uname -s)" = "Darwin" ]; then
#    # macOS has a different structure
#    JAVA="$ES_HOME/jdk.app/Contents/Home/bin/java"
#  else
#    JAVA="$ES_HOME/jdk/bin/java"
#  fi
#  JAVA_TYPE="bundled jdk"
#fi

             

            After that I don't have any problem with ElasticSearch and Bitbucket as two apps are using different java.

            Mateusz Pelczarski added a comment - I had this issue with version 7.6.0. Atlassian is providing jre with install_method but not with upgrade/archive one... Main problem is that both instances Bitbucket and ElasticSearch can't use one JAVA_HOME even when we edit /etc/profile only one instance will start. If we check set-jre-home.sh after install_method its pointing directly to atlassian_install/jre/ directory where java is stored.  To point to correct java version we want to use for elasticsearch the best way is to edit code in atlassian_install/elasticsearch/bin/elasticsearch-env   I just added this two lines: 38 JAVA= "java_directory" 39 JAVA_TYPE= "JAVA_HOME" and comment this lines: # if [ ! -z "$JAVA_HOME" ]; then # JAVA= "$JAVA_HOME/bin/java" # JAVA_TYPE= "JAVA_HOME" # else # if [ "$(uname -s)" = "Darwin" ]; then # # macOS has a different structure # JAVA= "$ES_HOME/jdk.app/Contents/Home/bin/java" # else # JAVA= "$ES_HOME/jdk/bin/java" # fi # JAVA_TYPE= "bundled jdk" #fi   After that I don't have any problem with ElasticSearch and Bitbucket as two apps are using different java.

            gszymoni added a comment -

            I have added a bash profile to the atlbitbucket user that runs the service.  After starting the service I don't see the repeating error any more!  I will continue to monitor this evening to make sure.

             

            The only reason I mentioned the upgrade to 7.5.0 was to rule out any possible fixes that may have been applied.  When contacting support I usually am asked if I tried upgrading   I suspect the issue I saw when upgrading is related to this issue, and the first time startup scripts could not run.  If it turns out that is not the case, I will certainly open a separate ticket to request help with that.

            gszymoni added a comment - I have added a bash profile to the atlbitbucket user that runs the service.  After starting the service I don't see the repeating error any more!  I will continue to monitor this evening to make sure.   The only reason I mentioned the upgrade to 7.5.0 was to rule out any possible fixes that may have been applied.  When contacting support I usually am asked if I tried upgrading   I suspect the issue I saw when upgrading is related to this issue, and the first time startup scripts could not run.  If it turns out that is not the case, I will certainly open a separate ticket to request help with that.

              Unassigned Unassigned
              eslaughter@atlassian.com Evan Slaughter
              Affected customers:
              8 This affects my team
              Watchers:
              20 Start watching this issue

                Created:
                Updated:
                Resolved: