CODEWITHSUNDEEP
elasticsearchsonarqube
PRF
PRF

Reputation: 831

SonarQube 6.7 failed to start because CONFIG_SECCOMP not compiled into kernel

I've just upgraded SonarQube from 6.0 to 6.7 LTS running in a CentOS 6 box, and noticed that ElasticSearch (ES) failed to start because the kernel (2.6.32-696.3.1.el6.x86_64) doesn't have seccomp available.

This is officially documented at System call filter check and a correct workaround for systems without this feature is to configure bootstrap.system_call_filter to false in elasticsearch.yml.

The issue here is because Sonar creates the ES configuration at startup, writing in $SONAR_HOME/temp/conf/es/elasticsearch.yml and I haven't found a way to set bootstrap.system_call_filter property.

I tried a natural (undocumented) way introducing sonar.search.bootstrap.system_call_filter and bootstrap.system_call_filter properties in sonar.properties but it doesn't work.

Upvotes: 5

Views: 4798

Answers (5)

Junjun
Junjun

Reputation: 21

For sonarqube docker image, setup additional environment to disable this feature when "docker run":

-e SONAR_SEARCH_JAVAADDITIONALOPTS="-Dbootstrap.system_call_filter=false"

Upvotes: 2

Lee
Lee

Reputation: 1

You could really cheat and edit /${SONAR_HOME}/elasticsearch/bin/elasticsearch.

Add

echo "bootstrap.system_call_filter = 'false'" >> 
/${SONAR_HOME}/temp/conf/es/elasticsearch.yml

before the "demonized" variable is set.

Upvotes: 0

Nicolas B.
Nicolas B.

Reputation: 7321

First of all: don't even try to update elasticsearch.yml . SonarQube self-manages its ElasticSearch component config, so any attempt of manual intervention will be harmful. (reminder: the only config file that should ever be modified to operate SonarQube is sonar.properties)

More interestingly regarding that seccomp component:

  • the seccomp requirement does come from underlying ElasticSearch requirement, and transitively applies to operating SonarQube
  • if you run SonarQube locally with default config (specifically: default sonar.search.host), then the seccomp check may not be fatal (i.e. just a warning)
  • if you did override sonar.search.host , then the first thing you should wonder is: does the ElasticSearch JVM really needs to listen on other interfaces than loopback ? (knowing that SonarQube uses ES locally, except with the Data Center Edition). If no good answer to that, then keep sonar.search.host at its default value.

Last but not least, the golden path here is obviously to follow the requirement (i.e. have seccomp available on your OS), even if that involves upgrading to a more recent Linux kernel. And to wrap it all up: we've edited SonarQube Requirements to transparently share this situation.

Upvotes: 0

kdeenkhoorn
kdeenkhoorn

Reputation: 91

We had the same problem. At first we used the above solution but after searching in the sonar code on github found the place where this setting should be placed:

Edit the sonar.properties file and change the line:

#sonar.search.javaAdditionalOpts=

to

sonar.search.javaAdditionalOpts=-Dbootstrap.system_call_filter=false

Upvotes: 9

beka
beka

Reputation: 71

Hi I tried to echo bootstrap.system_call_filter: 'false' to temp/conf/es/elasticsearch.yml, I see the line in that file, but got same error during start of sonarqube 6.7 on centos6.

Has someone tested that with success?

Upvotes: 0

Related Questions