ES 6.5.1 FATAL error on launch with JDK 11; no error / runs OK with JDK 1.8


#1

I installed ES 6.5.1 RPM

rpm -q elasticsearch
  elasticsearch-6.5.1-1.noarch

If I config

/etc/sysconfig/elasticsearch 
	JAVA_HOME=/usr/lib64/jvm/java-1.8.0-openjdk
	...

/usr/lib64/jvm/java-1.8.0-openjdk/bin/java -version
	openjdk version "1.8.0_181"
	OpenJDK Runtime Environment (IcedTea 3.9.0) (build 1.8.0_181-b13 suse-lp150.314.1-x86_64)
	OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

Launch is OK, and ES runs stable

systemctl status -l elasticsearch gentics-mesh
● elasticsearch.service - Elasticsearch
   Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/elasticsearch.service.d
           └─override.conf
   Active: active (running) since Thu 2018-11-22 13:36:27 PST; 156ms ago
     Docs: http://www.elastic.co
 Main PID: 31252 (elasticsearch)
    Tasks: 12 (limit: 9830)
   CGroup: /system.slice/elasticsearch.service
           ├─31252 /bin/bash /usr/share/elasticsearch/bin/elasticsearch -p /var/run/elasticsearch/elasticsearch.pid --quiet
           └─31273 /usr/lib64/jvm/java-1.8.0-openjdk/bin/java -cp /usr/share/elasticsearch/lib/* org.elasticsearch.tools.java_version_checker.JavaVersionChecker

If I switch to JDK 11

/etc/sysconfig/elasticsearch 
-	JAVA_HOME=/usr/lib64/jvm/java-1.8.0-openjdk
+	JAVA_HOME=/usr/lib64/jvm/java-11-openjdk-11
	...

/usr/lib64/jvm/java-11-openjdk-11/bin/java -version
	openjdk version "11.0.1" 2018-10-16
	OpenJDK Runtime Environment (build 11.0.1+13-suse-lp150.101.2-x8664)
	OpenJDK 64-Bit Server VM (build 11.0.1+13-suse-lp150.101.2-x8664, mixed mode)

Launch fails

==> /var/log/elasticsearch/elasticsearch.log <==
...

EDIT:

since FORUM complains

"Body is limited to 7000 characters; you entered 9530."

output's at ==> https://pastebin.com/raw/4vFe99tx


(Przemek Gomulka) #2

Hi Jole, thank you for reaching out.

Would you be able to show your plugin-security.policy for x-pack-watcher ?
Most likely it would be in "/usr/share/elasticsearch/modules/x-pack-watcher"

Could you also point to a place where you got your JDK from?

Please add following line
-Djava.security.debug=access,failure
to your elasticsearch jvm.options /etc/elasticsearch/jvm.options
And then provide us with logs from sudo journalctl -u elasticsearch

Possibly the problem described by a user here might be similar to yours:


#3

@pgomulka

Again: "Body is limited to 7000 characters; you entered 10664."

Srsly, that's really annoying.

Detailed responses to your questions are at:

https://pastebin.com/raw/ENUR8Ui6


(Przemek Gomulka) #4

@Jole
Are you sure you got your service restarted? I guess you don't get your access logs in /var/log/elasticsearch as well ?
I was hoping to see logs in a form like (successful startup):

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.io.FilePermission" "/home/vagrant/jdk-11.0.1/lib/security/cacerts" "read")

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.util.PropertyPermission" "com.sun.security.preserveOldDCEncoding" "read")

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.util.PropertyPermission" "sun.security.rsa.restrictRSAExponent" "read")

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")

Nov 30 19:49:29 opensuse-leap elasticsearch[12250]: access: access allowed ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.x509")

#5

@pgomulka

No, I didn't get it restarted. That's the problem -- it FAILS to start with jdk11:

systemctl status elasticsearch
	● elasticsearch.service - Elasticsearch
	   Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: disabled)
	  Drop-In: /etc/systemd/system/elasticsearch.service.d
	           └─override.conf
	   Active: failed (Result: exit-code) since Sat 2018-12-01 11:35:15 PST; 6min ago
	     Docs: http://www.elastic.co
	  Process: 1480 ExecStart=/usr/share/elasticsearch/bin/elasticsearch -p ${PID_DIR}/elasticsearch.pid --quiet (code=exited, status=1/FAILURE)
	 Main PID: 1480 (code=exited, status=1/FAILURE)
	    Tasks: 0 (limit: 9830)
	   CGroup: /system.slice/elasticsearch.service

Here's the full output from journalctl -u:

https://paste.fedoraproject.org/paste/BmzXVU8HduniouBNUv17Og/raw


(Przemek Gomulka) #6

@Jole I have managed to reproduce your problem locally with the JDK you have used.
https://download.opensuse.org/repositories/Java:/Factory/openSUSE_Leap_15.0/x86_64/java-11-openjdk-headless-11.0.1.0-lp150.101.2.x86_64.rpm

Interestingly enough I don't get that problem when I use a jdk downloaded from: https://jdk.java.net/11/
https://download.java.net/java/GA/jdk11/13/GPL/openjdk-11.0.1_linux-x64_bin.tar.gz

Similarly I don't get that problem when running JDK11 and elasticsearch on ubuntu. https://app.vagrantup.com/elastic/boxes/ubuntu-18.04-x86_64

I need more time to investigate why the problem occurs with JDK from SUSE repository you have used.
Bear in mind that the SUSE Leap 15 is not supported yet by elastic https://www.elastic.co/support/matrix

In meantime can you try to workaround with using the jdk from https://jdk.java.net/11/ ?

Let me know if that works


#7

Body is limited to 7000 characters; you entered 10455.
(can someone 'there' pls consider addressing this?)

==>
https://paste.fedoraproject.org/paste/DjhbSLG9nEVhBjUTSwbhdg

Could security policy be relevant here?

In Opensuse-packaged JDK 1.8, there's one:

/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/lib/security/java.policy

for JDK 11, there's two:

/usr/lib64/jvm/java-11-openjdk-11/lib/security/default.policy
/usr/lib64/jvm/java-11-openjdk-11/conf/security/java.policy

Their respective contents are

==>
https://paste.fedoraproject.org/paste/SdV-3SYRkCxUY4Ew97oojQ

comparing to Ubuntu's,

https://git.launchpad.net/ubuntu/+source/openjdk-lts/tree/src/java.base/share/conf/security/java.policy

https://git.launchpad.net/ubuntu/+source/openjdk-lts/tree/src/java.base/share/lib/security/default.policy

nothing different jumps out at me at 1st glance


(Przemek Gomulka) #8

@Jole
Glad to hear that this helped.
Thank you for tips and suggestions. These are very helpful and I will certainly check them.

The problem is on my list to fix, and I am sure we will be ready before the maintenance expires for 42


(Przemek Gomulka) #9

@Jole
would you be able to share with me your jvm.options file and the exact command you have used to get your access logs (the one with journalctl I guess) ?


#10

Glad to hear that this helped

Just to be clear, the launch with Opensuse Leap's JDK still is FAILing.

share with me your jvm.options file

cat etc/elasticsearch/jvm.options
    ## JVM configuration

    ################################################################
    ## IMPORTANT: JVM heap size
    ################################################################
    ##
    ## You should always set the min and max JVM heap
    ## size to the same value. For example, to set
    ## the heap to 4 GB, set:
    ##
    ## -Xms4g
    ## -Xmx4g
    ##
    ## See https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html
    ## for more information
    ##
    ################################################################

    # Xms represents the initial size of total heap space
    # Xmx represents the maximum size of total heap space

    -Xms1g
    -Xmx1g

    ################################################################
    ## Expert settings
    ################################################################
    ##
    ## All settings below this section are considered
    ## expert settings. Don't tamper with them unless
    ## you understand what you are doing
    ##
    ################################################################

    ## GC configuration
    -XX:+UseConcMarkSweepGC
    -XX:CMSInitiatingOccupancyFraction=75
    -XX:+UseCMSInitiatingOccupancyOnly

    ## G1GC Configuration
    # NOTE: G1GC is only supported on JDK version 10 or later.
    # To use G1GC uncomment the lines below.
    # 10-:-XX:-UseConcMarkSweepGC
    # 10-:-XX:-UseCMSInitiatingOccupancyOnly
    # 10-:-XX:+UseG1GC
    # 10-:-XX:InitiatingHeapOccupancyPercent=75

    ## optimizations

    # pre-touch memory pages used by the JVM during initialization
    -XX:+AlwaysPreTouch

    ## basic

    # explicitly set the stack size
    -Xss1m

    # set to headless, just in case
    -Djava.awt.headless=true

    # ensure UTF-8 encoding by default (e.g. filenames)
    -Dfile.encoding=UTF-8

    # use our provided JNA always versus the system one
    -Djna.nosys=true

    # turn off a JDK optimization that throws away stack traces for common
    # exceptions because stack traces are important for debugging
    -XX:-OmitStackTraceInFastThrow

    # flags to configure Netty
    -Dio.netty.noUnsafe=true
    -Dio.netty.noKeySetOptimization=true
    -Dio.netty.recycler.maxCapacityPerThread=0

    # log4j 2
    -Dlog4j.shutdownHookEnabled=false
    -Dlog4j2.disable.jmx=true

    -Djava.io.tmpdir=${ES_TMPDIR}

    ## heap dumps

    # generate a heap dump when an allocation from the Java heap fails
    # heap dumps are created in the working directory of the JVM
    -XX:+HeapDumpOnOutOfMemoryError

    # specify an alternative path for heap dumps; ensure the directory exists and
    # has sufficient space
    -XX:HeapDumpPath=/data/elasticsearch

    # specify an alternative path for JVM fatal error logs
    -XX:ErrorFile=/var/log/elasticsearch/hs_err_pid%p.log

    ## JDK 8 GC logging

    8:-XX:+PrintGCDetails
    8:-XX:+PrintGCDateStamps
    8:-XX:+PrintTenuringDistribution
    8:-XX:+PrintGCApplicationStoppedTime
    8:-Xloggc:/var/log/elasticsearch/gc.log
    8:-XX:+UseGCLogFileRotation
    8:-XX:NumberOfGCLogFiles=32
    8:-XX:GCLogFileSize=64m

    # JDK 9+ GC logging
    9-:-Xlog:gc*,gc+age=trace,safepoint:file=/var/log/elasticsearch/gc.log:utctime,pid,tags:filecount=32,filesize=64m
    # due to internationalization enhancements in JDK 9 Elasticsearch need to set the provider to COMPAT otherwise
    # time/date parsing will break in an incompatible way for some date patterns and locals
    9-:-Djava.locale.providers=COMPAT

    # temporary workaround for C2 bug with JDK 10 on hardware with AVX-512
    10-:-XX:UseAVX=2

    ## TEMP
    -Djava.security.debug=access,failure

the exact command you have used to get your access logs (the one with journalctl I guess)

journalctl -u elasticsearch