SonarQube starting Failed

Question

I installed SonarQube Version 7.9.1 on CentOS 7 and the service set to start with non root user. My vm.max_map_count is set to 262144.

sysctl vm.max_map_count
vm.max_map_count = 262144

Because of My SonarQube version I set the JDK in Wrapper.conf to

wrapper.java.command=/usr/lib/jvm/java-11-openjdk/bin/java

My sonar.log is:

--> 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.

2019.07.29 13:31:51 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
2019.07.29 13:31:51 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2019.07.29 13:31:51 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
2019.07.29 13:31:51 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
2019.07.29 13:31:51 INFO  app[][o.e.p.PluginsService] no modules loaded
2019.07.29 13:31:51 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
ERROR: [1] bootstrap checks failed
[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
2019.07.29 13:31:56 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 78
2019.07.29 13:31:56 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
2019.07.29 13:31:56 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped
<-- Wrapper Stopped

My es.log is:

2019.07.29 13:31:53 INFO  es[][o.e.e.NodeEnvironment] using [1] data paths, mounts [[/ (rootfs)]], net usable_space [31.1gb], net total_space [49.9gb], types [rootfs]
2019.07.29 13:31:53 INFO  es[][o.e.e.NodeEnvironment] heap size [494.9mb], compressed ordinary object pointers [true]
2019.07.29 13:31:53 INFO  es[][o.e.n.Node] node name [sonarqube], node ID [XhVUvjLfTS-JwFuXmFVL4Q]
2019.07.29 13:31:53 INFO  es[][o.e.n.Node] version[6.8.0], pid[60694], build[default/tar/65b6179/2019-05-15T20:06:13.172855Z], OS[Linux/3.10.0-957.21.3.el7.x86_64/amd64], JVM[Oracle Corporation/OpenJDK 64-Bit Server VM/11.0.4/11.0.4+11-LTS]
2019.07.29 13:31:53 INFO  es[][o.e.n.Node] JVM arguments [-XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -Des.networkaddress.cache.ttl=60, -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Djava.io.tmpdir=/opt/sonarqube/temp, -XX:ErrorFile=../logs/es_hs_err_pid%p.log, -Des.enforce.bootstrap.checks=true, -Xms512m, -Xmx512m, -XX:+HeapDumpOnOutOfMemoryError, -Des.path.home=/opt/sonarqube/elasticsearch, -Des.path.conf=/opt/sonarqube/temp/conf/es, -Des.distribution.flavor=default, -Des.distribution.type=tar]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] loaded module [analysis-common]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] loaded module [lang-painless]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] loaded module [mapper-extras]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] loaded module [parent-join]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] loaded module [percolator]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] loaded module [reindex]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] loaded module [repository-url]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] loaded module [transport-netty4]
2019.07.29 13:31:53 INFO  es[][o.e.p.PluginsService] no plugins loaded
2019.07.29 13:31:54 WARN  es[][o.e.d.c.s.Settings] [http.enabled] setting was deprecated in Elasticsearch and will be removed in a future release! See the breaking changes documentation for the next major version.
2019.07.29 13:31:55 INFO  es[][o.e.d.DiscoveryModule] using discovery type [zen] and host providers [settings]
2019.07.29 13:31:55 INFO  es[][o.e.n.Node] initialized
2019.07.29 13:31:55 INFO  es[][o.e.n.Node] starting ...
2019.07.29 13:31:56 INFO  es[][o.e.t.TransportService] publish_address {127.0.0.1:9001}, bound_addresses {127.0.0.1:9001}
2019.07.29 13:31:56 INFO  es[][o.e.b.BootstrapChecks] explicitly enforcing bootstrap checks
2019.07.29 13:31:56 ERROR es[][o.e.b.Bootstrap] node validation exception
[1] bootstrap checks failed
[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
2019.07.29 13:31:56 INFO  es[][o.e.n.Node] stopping ...
2019.07.29 13:31:56 INFO  es[][o.e.n.Node] stopped
2019.07.29 13:31:56 INFO  es[][o.e.n.Node] closing ...
2019.07.29 13:31:56 INFO  es[][o.e.n.Node] closed

Solution

To apply these configuration permanently, edit /etc/sysctl.d/99-sonarqube.conf or /etc/sysctl.conf and add:

sysctl -w vm.max_map_count=262144
sysctl -w fs.file-max=65536
ulimit -n 65536
ulimit -u 2048`

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 2048 threads

Or if you want to apply these settings on current session, just enter each command in terminal:

sysctl -w vm.max_map_count=262144
sysctl -w fs.file-max=65536
ulimit -n 65536
ulimit -u 2048

Hope this helps!

Comments

[Amir Soleimani Borujerdi]

Where I should set vm.max_map_count in CentOS 7? there are multiple place that mentioned in link

[Nick Mathison]

I believe your main issue is the max file descriptors [4096]. I followed the official directions mentioned in the second link section "Running SonarQube as a Service on Linux with SystemD". This ensured that the max file descriptors was actually set. You'll see in the sample /etc/systemd/system/sonarqube.service file, they set the LimitNOFILE variable, which based on your error logs.

[Amir Soleimani Borujerdi]

I had a problem with my Postgres database, another problem is vm.max_map_count, when I set it with sysctl -w vm.max_map_count=262144, SonarQube run and it is accessible, but after restarting, again it should be set manually and I think LimitNOFILE=65536 LimitNPROC=8192 in service file is not enough.

[Amir Soleimani Borujerdi]

Commands are not permanent, I changed it in files and it works fine, thank you!