Updating to latest SonarQube LTA 2025.1

I’m running RHEL 8 with Java 17, specifically:
openjdk version “17.0.14” 2025-01-21 LTS
OpenJDK Runtime Environment (Red_Hat-17.0.14.0.7-1) (build 17.0.14+7-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.14.0.7-1) (build 17.0.14+7-LTS, mixed mode, sharing)

ElasticSearch fails to start with following error:

2025.02.13 14:02:23 ERROR es[][o.e.b.Elasticsearch] fatal exception while booting Elasticsearch
java.lang.ExceptionInInitializerError: null
        at org.elasticsearch.nativeaccess.NativeAccess.instance(NativeAccess.java:25) ~[elasticsearch-native-8.16.1.jar:?]                                                                                                          
        at org.elasticsearch.bootstrap.Elasticsearch.initializeNatives(Elasticsearch.java:283) ~[elasticsearch-8.16.1.jar:?]                                                                                                        
        at org.elasticsearch.bootstrap.Elasticsearch.initPhase2(Elasticsearch.java:169) ~[elasticsearch-8.16.1.jar:?]                                                                                                               
        at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:74) ~[elasticsearch-8.16.1.jar:?]
Caused by: java.lang.UnsupportedOperationException: Failed to allocate closure
        at com.sun.jna.Native.registerMethod(Native Method) ~[?:?]
        at com.sun.jna.Native.register(Native.java:1906) ~[?:?]
        at com.sun.jna.Native.register(Native.java:1775) ~[?:?]
        at org.elasticsearch.nativeaccess.jna.JnaZstdLibrary.<init>(JnaZstdLibrary.java:33) ~[?:?]
        at org.elasticsearch.nativeaccess.lib.NativeLibraryProvider.getLibrary(NativeLibraryProvider.java:59) ~[elasticsearch-native-8.16.1.jar:?]                                                                                  
        at org.elasticsearch.nativeaccess.AbstractNativeAccess.<init>(AbstractNativeAccess.java:31) ~[elasticsearch-native-8.16.1.jar:?]                                                                                            
        at org.elasticsearch.nativeaccess.PosixNativeAccess.<init>(PosixNativeAccess.java:35) ~[elasticsearch-native-8.16.1.jar:?]                                                                                                  
        at org.elasticsearch.nativeaccess.LinuxNativeAccess.<init>(LinuxNativeAccess.java:94) ~[elasticsearch-native-8.16.1.jar:?]                                                                                                  
        at org.elasticsearch.nativeaccess.NativeAccessHolder.<clinit>(NativeAccessHolder.java:29) ~[elasticsearch-native-8.16.1.jar:?]                                                                                              
        ... 4 more

zstd and zlib are installed. Even setting logs to DEBUG, I can’t seem to get any more detail on what’s failing.

Adding notes here as I work on this (hopefully to help others also)…

So (as error does indicate) the JNA library was missing. I manually added and now I’m on to more normal errors related to memory config.

Hoping someone might comment or share insight on JNA situation, seems odd to have to manually handle, perhaps I missed something in the docs.

1 Like

Hi,

Do you still have the old es.log? It would be good to see it from startup through this error.

I’m running the Ubuntu flavor of the same Java distro & 2025.1 started up for me just fine.

openjdk 17.0.14 2025-01-21
OpenJDK Runtime Environment (build 17.0.14+7-Ubuntu-122.04.1)
OpenJDK 64-Bit Server VM (build 17.0.14+7-Ubuntu-122.04.1, mixed mode, sharing)

 
Thx,
Ann

that is literally the whole log file except for these 4 lines in the beginning:

2025.02.18 09:01:52 INFO  es[][o.e.n.Node] stopping ...
2025.02.18 09:01:52 INFO  es[][o.e.n.Node] stopped
2025.02.18 09:01:52 INFO  es[][o.e.n.Node] closing ...
2025.02.18 09:01:52 INFO  es[][o.e.n.Node] closed

Hi,

You mentioned adding JNA. Did you do it in a filesystem mounted iwht the noexec option? Because, per Elasticsearch docs, that won’t work.

 
HTH,
Ann

1 Like

We ultimately isolated the issue down to the configuration of the /tmp directory.