Cannot start SonarQube 7.9.2

SonarQube Server / Community Build
1

Hello,

I am trying to upgrade from SonarQube 6.7.7 to 7.9.2, but it is failing to start Elasticsearch. At first it was a typical problem with max file descriptors. Having fixed that, it’s still not working, and the logs don’t give any clues, or at least I cannot find them.
Some system info:

java -version
java version "11.0.4" 2019-07-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.4+10-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.4+10-LTS, mixed mode)

uname -a
Linux sonar001 2.6.32-754.18.2.el6.x86_64 #1 SMP Wed Aug 14 16:26:59 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
 
free -h
             total       used       free     shared    buffers     cached
Mem:           15G        13G       2.1G       376K       485M        11G
-/+ buffers/cache:       1.7G        13G
Swap:           0B         0B         0B

The logs say:

sonar.log:

-> Wrapper Started as Daemon
Launching a JVM...
Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
  Copyright 1999-2006 Tanuki Software, Inc.  All Rights Reserved.

2020.02.07 08:47:36 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonar/sonarqube-7.9.2/temp
2020.02.07 08:47:36 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2020.02.07 08:47:36 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonar/sonarqube-7.9.2/elasticsearch]: /opt/sonar/sonarqube-7.9.2/elasticsearch/bin/elasticsearch
2020.02.07 08:47:36 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
2020.02.07 08:47:37 INFO  app[][o.e.p.PluginsService] no modules loaded
2020.02.07 08:47:37 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
ERROR: [1] bootstrap checks failed
[1]: system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk
2020.02.07 08:47:43 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 78
2020.02.07 08:47:43 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
2020.02.07 08:47:43 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped
<-- Wrapper Stopped

last few lines from es.log:

2020.02.07 08:47:43 INFO  es[][o.e.n.Node] initialized
2020.02.07 08:47:43 INFO  es[][o.e.n.Node] starting ...
2020.02.07 08:47:43 DEBUG es[][i.n.c.MultithreadEventLoopGroup] -Dio.netty.eventLoopThreads: 8
2020.02.07 08:47:43 DEBUG es[][i.n.c.n.NioEventLoop] -Dio.netty.noKeySetOptimization: true
2020.02.07 08:47:43 DEBUG es[][i.n.c.n.NioEventLoop] -Dio.netty.selectorAutoRebuildThreshold: 512
2020.02.07 08:47:43 DEBUG es[][i.n.u.i.PlatformDependent] org.jctools-core.MpscChunkedArrayQueue: unavailable
2020.02.07 08:47:43 DEBUG es[][o.e.t.n.Netty4Transport] using profile[default], worker_count[8], port[9001], bind_host[[127.0.0.1]], publish_host[[127.0.0.1]], receive_predictor[64kb->64kb]
2020.02.07 08:47:43 DEBUG es[][o.e.t.TcpTransport] binding server bootstrap to: [127.0.0.1]
2020.02.07 08:47:43 DEBUG es[][i.n.c.DefaultChannelId] -Dio.netty.processId: 19194 (auto-detected)
2020.02.07 08:47:43 DEBUG es[][i.n.u.NetUtil] -Djava.net.preferIPv4Stack: false
2020.02.07 08:47:43 DEBUG es[][i.n.u.NetUtil] -Djava.net.preferIPv6Addresses: false
2020.02.07 08:47:43 DEBUG es[][i.n.u.NetUtil] Loopback interface: lo (lo, 0:0:0:0:0:0:0:1%lo)
2020.02.07 08:47:43 DEBUG es[][i.n.u.NetUtil] /proc/sys/net/core/somaxconn: 128
2020.02.07 08:47:43 DEBUG es[][i.n.c.DefaultChannelId] -Dio.netty.machineId: 0e:c7:5d:ff:fe:de:05:b0 (auto-detected)
2020.02.07 08:47:43 DEBUG es[][i.n.u.i.InternalThreadLocalMap] -Dio.netty.threadLocalMap.stringBuilder.initialSize: 1024
2020.02.07 08:47:43 DEBUG es[][i.n.u.i.InternalThreadLocalMap] -Dio.netty.threadLocalMap.stringBuilder.maxSize: 4096
2020.02.07 08:47:43 DEBUG es[][i.n.u.ResourceLeakDetector] -Dio.netty.leakDetection.level: simple
2020.02.07 08:47:43 DEBUG es[][i.n.u.ResourceLeakDetector] -Dio.netty.leakDetection.targetRecords: 4
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.numHeapArenas: 5
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.numDirectArenas: 5
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.pageSize: 8192
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.maxOrder: 11
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.chunkSize: 16777216
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.tinyCacheSize: 512
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.smallCacheSize: 256
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.normalCacheSize: 64
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.maxCachedBufferCapacity: 32768
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.cacheTrimInterval: 8192
2020.02.07 08:47:43 DEBUG es[][i.n.b.PooledByteBufAllocator] -Dio.netty.allocator.useCacheForAllThreads: true
2020.02.07 08:47:43 DEBUG es[][i.n.b.ByteBufUtil] -Dio.netty.allocator.type: pooled
2020.02.07 08:47:43 DEBUG es[][i.n.b.ByteBufUtil] -Dio.netty.threadLocalDirectBufferSize: 0
2020.02.07 08:47:43 DEBUG es[][i.n.b.ByteBufUtil] -Dio.netty.maxThreadLocalCharBufferSize: 16384
2020.02.07 08:47:43 DEBUG es[][o.e.t.TcpTransport] Bound profile [default] to address {127.0.0.1:9001}
2020.02.07 08:47:43 INFO  es[][o.e.t.TransportService] publish_address {127.0.0.1:9001}, bound_addresses {127.0.0.1:9001}
2020.02.07 08:47:43 INFO  es[][o.e.b.BootstrapChecks] explicitly enforcing bootstrap checks
2020.02.07 08:47:43 ERROR es[][o.e.b.Bootstrap] node validation exception
[1] bootstrap checks failed
[1]: system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk
2020.02.07 08:47:43 INFO  es[][o.e.n.Node] stopping ...
2020.02.07 08:47:43 INFO  es[][o.e.n.Node] stopped
2020.02.07 08:47:43 INFO  es[][o.e.n.Node] closing ...
2020.02.07 08:47:43 INFO  es[][o.e.n.Node] closed

I do not know what is wrong. Please help.

Regards,
Miki

2

Welcome :slight_smile:

Did you check all requirements https://docs.sonarqube.org/latest/requirements/requirements/ ?
There is a section for Linux - no anchor link sorry - that has:

Linux

If you’re running on Linux, you must ensure that:

  • vm.max_map_count is greater or equals to 262144
  • fs.file-max is greater or equals to 65536
  • the user running SonarQube can open at least 65536 file descriptors
  • the user running SonarQube can open at least 4096 threads

You can see the values with the following commands:

sysctl vm.max_map_count
sysctl fs.file-max
ulimit -n
ulimit -u

Might be the vm.max_map_count in your case.

The relevant ES docs
https://www.elastic.co/guide/en/elasticsearch/reference/master/_system_call_filter_check.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html

Gilbert

3

Looks like it was not related to the system limits, but seccomp filter. Adding “sonar.search.javaAdditionalOpts=-Dbootstrap.system_call_filter=false” to $SONARQUBEHOME/conf/sonar.properties helped and Sonar 7.9.2 started.
Thank you for your help.