Docker-sonarqube: Sonarqube crashed still with latest image

Created on 29 Jun 2019 · 59Comments · Source: SonarSource/docker-sonarqube

Hi,

I was running sonarqube on aws and via docker using docker run -d -p 9000:9000 sonarqube. I also tried sudo docker run -d -p 9000:9000 sonarqube.

Basically i did as below and opened up the port groups on aws. However, docker keeps running into a segmentation fault as seen after I try access my publicip:9000 as showb below

I then restart the VM in aws and check my docker logs and it states that

ubuntu@ip-10-0-0-68:~$ docker logs 41cf22d6ae9e
2019.06.29 01:36:36 WARN app[][o.s.application.App] SonarQube will require Java 11+ starting on next version
2019.06.29 01:36:36 INFO app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
2019.06.29 01:36:36 INFO app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2019.06.29 01:36:36 INFO app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
2019.06.29 01:36:36 INFO app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2019.06.29 01:36:37 INFO app[][o.e.p.PluginsService] no modules loaded
2019.06.29 01:36:37 INFO app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]

Has this been resolved ?

Source

leeadh

Most helpful comment

I have a similar error with the last image :
ERROR: [1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

It only occurs if I try to configure sonarqube with postgresql. If I don't touch the default config, it starts correctly with the H2 datasource.

try this:
sysctl -w vm.max_map_count=262144

as discussed here:
https://stackoverflow.com/questions/51445846/elastic-search-max-virtual-memory-areas-vm-max-map-count-65530-is-too-low-inc

bdavis-tc on 2 Jul 2019

👍61 🎉12 ❤9

All 59 comments

Same Issue here - SonarQuebe does not get ready, ingress returns 503.
log output:

2019.07.02 07:26:07 WARN  app[][o.s.application.App] SonarQube will require Java 11+ starting on next version
2019.07.02 07:26:07 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
2019.07.02 07:26:07 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2019.07.02 07:26:08 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.02 07:26:08 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2019.07.02 07:26:08 INFO  app[][o.e.p.PluginsService] no modules loaded
2019.07.02 07:26:08 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]

Image: sonarqube:7.8-community

Aypahyo on 2 Jul 2019

I am seeing the following in the log:

11:27:21 ERROR: [2] bootstrap checks failed
11:27:21 [1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
11:27:21 [2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

wburgers on 2 Jul 2019

👍22

I have a similar error with the last image :
ERROR: [1] bootstrap checks failed
It only occurs if I try to configure sonarqube with postgresql. If I don't touch the default config, it starts correctly with the H2 datasource.

tmeedend on 2 Jul 2019

👍22 😕1

While using the suggested docker-compose.yml with image: sonarqube:7.9-community, I get the following error:

db_1         | 2019-07-02 15:33:41.440 UTC [1] LOG:  database system is ready to accept connections
sonarqube_1  | 2019.07.02 15:33:41 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
sonarqube_1  | 2019.07.02 15:33:41 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
sonarqube_1  | 2019.07.02 15:33:42 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
sonarqube_1  | 2019.07.02 15:33:42 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
sonarqube_1  | 2019.07.02 15:33:42 INFO  app[][o.e.p.PluginsService] no modules loaded
sonarqube_1  | 2019.07.02 15:33:42 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
sonarqube_1  | OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
sonarqube_1  | ERROR: [1] bootstrap checks failed
sonarqube_1  | [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
sonarqube_1  | 2019.07.02 15:33:50 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 78
sonarqube_1  | 2019.07.02 15:33:50 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
sonarqube_1  | 2019.07.02 15:33:50 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped
sonarqube_sonarqube_1 exited with code 0

However when I change the sonarqube image to sonarqube:7.7-community everything seems to work fine.

As @tmeedend mentioned, if you remove the db connection sonar.jdbc.url=jdbc:postgresql://db:5432/sonar from the env vars, even the 7.9 image runs fine.

Ubuntu 18.04.2
Docker version 18.09.6
docker-compose version 1.17.1

senart on 2 Jul 2019

👍3 👎1

I have a similar error with the last image :
ERROR: [1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

It only occurs if I try to configure sonarqube with postgresql. If I don't touch the default config, it starts correctly with the H2 datasource.

try this:
sysctl -w vm.max_map_count=262144

as discussed here:
https://stackoverflow.com/questions/51445846/elastic-search-max-virtual-memory-areas-vm-max-map-count-65530-is-too-low-inc

bdavis-tc on 2 Jul 2019

👍61 🎉12 ❤9

Confirming that sysctl -w vm.max_map_count=262144 fixes the issue for me. Thanks!

senart on 2 Jul 2019

👍26 ❤11 🎉7

Hello @senart,
How did You set this option "sysctl -w vm.max_map_count=262144"?
Inside container or directly on host?

Best Regards,

marta1213 on 4 Jul 2019

👍4

Directly on the host. Starting the docker-compose afterwards worked as expected.

senart on 4 Jul 2019

🎉3 ❤2

Unfortunately this fix won't work on AWS Fargate. This is what I'm getting from Elasticsearch with sonarqube:7.9-community:

```
ERROR: [2] bootstrap checks failed

Sodki on 4 Jul 2019

👍15

My issue above seems to be different.
I am using a helm chart that has an init-sysctl container. The log file of that container reads:
vm.max_map_count = 262144
So my assumption is that this is covered.

I am a bit stuck on how to continue the analysis, what would I inspect next?

Aypahyo on 4 Jul 2019

I've managed to get this started on Fargate. There were two different issues, like I've mentioned above:

I had to properly configure ulimits on my ECS task definition, something like:

"ulimits": [
  {
    "name": "nofile",
    "softLimit": 65535,
    "hardLimit": 65535
  }
]

I've disabled mmap in ElasticSearch, which gets rid of the max_map_count setting requirement. This can be done by configuring the sonar.search.javaAdditionalOpts SonarQube setting. I wasn't able to do it with an environment variable, since ECS seems to be eating them, but in the end I just passed it as a parameter to the container, which works since the entrypoint is set and consumes arguments properly. In my case:

"command": [
  "-Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmapfs=false"
]

Hopefully this information will help some people.

Sodki on 4 Jul 2019

👍46 ❤11 🎉9 🚀6 😕3

db_1         | LOG:  database system is ready to accept connections
sonarqube_1  | 2019.07.08 09:22:12 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
sonarqube_1  | 2019.07.08 09:22:12 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
sonarqube_1  | 2019.07.08 09:22:12 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
sonarqube_1  | 2019.07.08 09:22:12 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
sonarqube_1  | 2019.07.08 09:22:12 INFO  app[][o.e.p.PluginsService] no modules loaded
sonarqube_1  | 2019.07.08 09:22:12 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
sonarqube_1  | OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
sonarqube_1  | 2019.07.08 09:22:16 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 1
sonarqube_1  | 2019.07.08 09:22:16 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
sonarqube_1  | 2019.07.08 09:22:16 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped

i have the same situation with @senart ;
Docker version 18.09.7
centos 7.6.1810
docker-compose version 1.21.2
sysctl -w vm.max_map_count=262144, i hava done this, but it doesnot work

oldthreefeng on 8 Jul 2019

👍2

@oldthreefeng You have a different problem, your ElasticSearch exits with code 1, so my suggestion is check your ElasticSearch logs to see exactly why it failed.

Sodki on 8 Jul 2019

I do have same problem than @oldthreefeng . I'm trying to run SonarQube 7.9.1-community on Kubernetes 1.14. Just trying to find my way to read ElasticSearch logs.

2019-07-16T07:50:53.181778215+02:00 05:50:53.177 [main] WARN org.sonar.application.config.AppSettingsLoaderImpl - Configuration file not found: /opt/sonarqube/conf/sonar.properties
2019-07-16T07:50:53.479127048+02:00 2019.07.16 05:50:53 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
2019-07-16T07:50:53.512036657+02:00 2019.07.16 05:50:53 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2019-07-16T07:50:53.630256779+02:00 2019.07.16 05:50:53 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-16T07:50:53.69131519+02:00 2019.07.16 05:50:53 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2019-07-16T07:50:54.370498376+02:00 2019.07.16 05:50:54 INFO  app[][o.e.p.PluginsService] no modules loaded
2019-07-16T07:50:54.372477693+02:00 2019.07.16 05:50:54 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
2019-07-16T07:50:54.556949896+02:00 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-16T07:50:58.977930366+02:00 2019.07.16 05:50:58 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 1
2019-07-16T07:50:58.983149202+02:00 2019.07.16 05:50:58 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
2019-07-16T07:50:58.985605818+02:00 2019.07.16 05:50:58 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped

edit. I found some older but similar issue which root cause was Elastic Search cannot be run as a root user. At the moment I really do have hard times to read es.log since container is crashing so i'm not able to login to container. Maybe it would be good to somehow forward ES logs to stdout and stderr, so reading logs would be easier.

suulperi on 16 Jul 2019

If you know exactly where the log file is, you can docker cp it out, even on a stopped container.

On SQ 7.9.1, logs are located inside the container in /opt/sonarqube/logs :

access.log
ce.log
es.log
sonar.log
web.log

Otherwise, you can restart the container with another entrypoint and explore it : https://stackoverflow.com/a/48892801/1574606

About the forwarding of ES log to the output, i duly note that this is a requested feature and will suggest it for https://jira.sonarsource.com/browse/MMF-1604

pierre-guillot-sonarsource on 16 Jul 2019

For me the error occurs only on amazon Linux,
on my windows machine running the sonar compose with postgress everything is working fine:

on amazon linux I get this error:

> 2019.07.16 07:25:49 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
> 
> 
> 2019.07.16 07:25:49 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
> 
> 
> 2019.07.16 07:25:50 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.16 07:25:50 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
> 
> 
> 2019.07.16 07:25:50 INFO  app[][o.e.p.PluginsService] no modules loaded
> 
> 
> 2019.07.16 07:25:50 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
> 
> 
> OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
> 
> 
> ERROR: [1] bootstrap checks failed
> 
> 
> [1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
> 
> 
> 2019.07.16 07:25:59 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 78
> 
> 
> 2019.07.16 07:25:59 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
> 
> 
> 2019.07.16 07:25:59 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped

What I already tried:

in /etc/sysctl.conf I added:

fs.file-max = 100000
vm.max_map_count = 262144

2.in /etc/security/limits.conf changes:

> *       hard    nofile  1048576
> *       soft    nofile  1048576
> *       hard    nproc   1048576
> *       soft    nproc   1048576

sudo sysctl -w vm.max_map_count=262144
verified that:

> cat /proc/sys/fs/file-max
> 782613

My compose:

version: '3.1'
services:
  sonarqube:
    image: sonarqube
    container_name: sonarqube
    depends_on:
      - postgresql
    ports:
      - "9000:9000"
    environment:
      - sonar.jdbc.url=jdbc:postgresql://postgresql:5432/sonar
    #command: "-Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmapfs=false"
    volumes:
      - sonarqube_conf:/opt/sonarqube/conf
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions

  postgresql:
    image: postgres
    container_name: postgresql
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data

volumes:
  sonarqube_conf:
  sonarqube_data:
  sonarqube_extensions:

shacharaj on 16 Jul 2019

👍4

If you know exactly where the log file is, you can docker cp it out, even on a stopped container.

On SQ 7.9.1, logs are located inside the container in /opt/sonarqube/log :

access.log

ce.log

es.log

sonar.log

web.log

Thanks for your input!
It seems to be so even kubectl includes cp-option it won't work with it if container/pod is in waiting state. Have to try to find some other solution.

edit. I don't how reliable is this output when i tried to copy:

root@master-p:~# kubectl cp sonarqube/sonarqube-server-6d9f66df9d-6ss6p:/opt/sonarqube/log .
tar: Removing leading `/' from member names
tar: /opt/sonarqube/log: Cannot stat: No such file or directory

suulperi on 16 Jul 2019

My bad, its /opt/sonarqube/logs with a S at the end of logs.

docker cp CONTAINER_ID:/opt/sonarqube/logs .

pierre-guillot-sonarsource on 16 Jul 2019

Thanks now command worked during container startup. Anyway it was able to pull only sonar.log. When i tried to copy only es.log result below

root@master-p:~# kubectl cp sonarqube/sonarqube-server-6d9f66df9d-bdnml:/opt/sonarqube/logs/es.log .
tar: Removing leading `/' from member names
tar: /opt/sonarqube/logs/es.log: Cannot stat: No such file or directory

suulperi on 16 Jul 2019

Extract the folder. Maybe there is no es.log, because it crash before.

pierre-guillot-sonarsource on 16 Jul 2019

Yep. That is true.

root@master-p:~# kubectl exec sonarqube-server-667755b9f8-b4dnq -n sonarqube -- ls -la /opt/sonarqube/logs/
total 20
drwxr-xr-x 1 sonarqube sonarqube 4096 Jul 16 09:11 .
drwxr-xr-x 1 sonarqube sonarqube 4096 Jul 10 12:32 ..
-rw-r--r-- 1 sonarqube sonarqube   88 Jul 10 12:21 README.txt
-rw-r--r-- 1 sonarqube sonarqube  692 Jul 16 09:11 sonar.log

suulperi on 16 Jul 2019

Please provide the full log and the steps to reproduce the problem

pierre-guillot-sonarsource on 16 Jul 2019

2019-07-16T15:13:10.168811793+02:00 13:13:10.161 [main] WARN org.sonar.application.config.AppSettingsLoaderImpl - Configuration file not found: /opt/sonarqube/conf/sonar.properties
2019-07-16T15:13:10.518807941+02:00 2019.07.16 13:13:10 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
2019-07-16T15:13:10.578643291+02:00 2019.07.16 13:13:10 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2019-07-16T15:13:10.757209823+02:00 2019.07.16 13:13:10 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-16T15:13:10.859887546+02:00 2019.07.16 13:13:10 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2019-07-16T15:13:11.456811146+02:00 2019.07.16 13:13:11 INFO  app[][o.e.p.PluginsService] no modules loaded
2019-07-16T15:13:11.458854619+02:00 2019.07.16 13:13:11 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
2019-07-16T15:13:11.519148858+02:00 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-16T15:13:15.286139248+02:00 2019.07.16 13:13:15 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 1
2019-07-16T15:13:15.287856877+02:00 2019.07.16 13:13:15 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
2019-07-16T15:13:15.288865436+02:00 2019.07.16 13:13:15 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped

Do deployment on Kubernetes version 1.14. Using PostgreSQL Server 10.9 (Docker Image)
SonarQube Deployment. Do next things before running deployment

Create Namespace called sonarqube
2, Create Persistent Volume Claims "sonarqube-data-pv-claim", "sonarqube-conf-pv-claim", and "sonarqube-extensions-pv-claim" with your suitable storage configurations
Use same secrets than with PostgreSQL installation

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sonarqube-server
  namespace: sonarqube
spec:
  selector:
    matchLabels:
      name: sonarqube-server
  replicas: 1   
  template:
    metadata:
      name: sonarqube-server
      labels:
        name: sonarqube-server
    spec:
      containers:
      - name: sonarqube-server
        image: sonarqube:7.9.1-community
        env:
        - name: SONARQUBE_JDBC_PASSWORD
          valueFrom:
            secretKeyRef:
              name: sonarqube-db-secret
              key: password
        - name: SONARQUBE_JDBC_URL
          value: jdbc:postgresql://sonarqube-postgres:5432/sonar
        volumeMounts:
        - mountPath: "/opt/sonarqube/conf/"
          name: sonarqube-conf
        - mountPath: "/opt/sonarqube/data/"
          name: sonarqube-data
        - mountPath: "/opt/sonarqube/extensions/"
          name: sonarqube-extensions
        ports:
        - containerPort: 9000
      volumes:
        - name: sonarqube-conf
          persistentVolumeClaim:
            claimName: sonarqube-conf-pv-claim
        - name: sonarqube-data
          persistentVolumeClaim:
            claimName: sonarqube-data-pv-claim
        - name: sonarqube-extensions
          persistentVolumeClaim:
            claimName: sonarqube-extensions-pv-claim

suulperi on 16 Jul 2019

What is the content of your volume sonarqube-conf?

pierre-guillot-sonarsource on 16 Jul 2019

```
root@master-p:~# kubectl exec sonarqube-server-667755b9f8-4zzwq -n sonarqube -- ls -la /opt/sonarqube/conf/
total 28
drwxr-xr-x 3 root root 4096 Jul 16 09:05 .
drwxr-xr-x 1 sonarqube sonarqube 4096 Jul 10 12:32 ..
drwx------ 2 root root 16384 Jul 16 09:05 lost+found
´´´

suulperi on 16 Jul 2019

If you know exactly where the log file is, you can docker cp it out, even on a stopped container.

On SQ 7.9.1, logs are located inside the container in /opt/sonarqube/logs :

access.log

ce.log

es.log

sonar.log

web.log

Otherwise, you can restart the container with another entrypoint and explore it : https://stackoverflow.com/a/48892801/1574606

About the forwarding of ES log to the output, i duly note that this is a requested feature and will suggest it for https://jira.sonarsource.com/browse/MMF-1604

Thanks for your input! I found the problem
in my es.log ,

java.lang.IllegalStateException: Unable to access 'path.data' (/opt/sonarqube/data/es6)
    at org.elasticsearch.bootstrap.FilePermissionUtils.addDirectoryPath(FilePermissionUtils.java:70) ~[elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Security.addFilePermissions(Security.java:299) ~[elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Security.createPermissions(Security.java:254) ~[elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Security.configure(Security.java:123) ~[elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:207) ~[elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:333) [elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:159) [elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:150) [elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) [elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124) [elasticsearch-cli-6.8.0.jar:6.8.0]
    at org.elasticsearch.cli.Command.main(Command.java:90) [elasticsearch-cli-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:116) [elasticsearch-6.8.0.jar:6.8.0]
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:93) [elasticsearch-6.8.0.jar:6.8.0]

docker-compose.yml

version: "2"

services:
  sonarqube:
    image: "sonarqube:7.9-community"
    ports:
      - "9988:9000"
    networks:
      - sonarnet
    depends_on:
      - db
    environment:
      - sonar.jdbc.url=jdbc:postgresql://db:5432/sonar
    volumes:
      #- /data/docker/sonarqube/conf:/opt/sonarqube/conf
      - /data/docker/sonarqube/data:/opt/sonarqube/data
      - /data/docker/sonarqube/logs:/opt/sonarqube/logs
      - /data/docker/sonarqube/extensions:/opt/sonarqube/extensions

  db:
    image: postgres:9.6.14
    networks:
      - sonarnet
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
    volumes:
      - /data/docker/sonarqube/postgresql:/var/lib/postgresql
      # This needs explicit mapping due to https://github.com/docker-library/postgres/blob/4e48e3228a30763913ece952c611e5e9b95c8759/Dockerfile.template#L52
      - /data/docker/sonarqube/postgresql_data:/var/lib/postgresql/data

networks:
  sonarnet:
    driver: bridge

so , I do this .
```
sudo chmod 777 /data/docker/sonarqube/data /data/docker/sonarqube/logs /data/docker/sonarqube/extensions
````
@suulperi try this.

oldthreefeng on 19 Jul 2019

👍5

Finally solved. With Kubernetes you must specify correct fsgroup for pod/container.

securityContext:
   fsGroup: 999

suulperi on 20 Jul 2019

👍1

I'm seeing this issue again.

cat /proc/sys/vm/max_map_count
262144

yet, when running the container I get:

[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

ardevd on 30 Jul 2019

did you ran cat /proc/sys/vm/max_map_count on the host, or inside the container ?

pierre-guillot-sonarsource on 30 Jul 2019

On the host. It used to work just fine but after a recent update the container just won't work.

ardevd on 30 Jul 2019

removing and recreating the docker container resolved the issue.

ardevd on 31 Jul 2019

If I am within GCP Kubernetes, does the host means the cluster? I am having the same max_heap_count issue and I am wondering where need to run this to fix it.

pascallalonde on 1 Aug 2019

With Kubernetes you need to run this on each pods you use. People usually have an init-container running with root privilege, executing theses commands. Then you can run the SQ image.

pierre-guillot-sonarsource on 2 Aug 2019

ERROR: [2] bootstrap checks failed
[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
[2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]```

in my case the only thing that helped was running docker with a flag:

docker run --ulimit nofile=90000:90000 ...

regentov on 12 Aug 2019

👍1

Finally solved. With Kubernetes you must specify correct fsgroup for pod/container.
securityContext:
   fsGroup: 999

How can I use that configuration on the deployment YAML? I'm getting the same error usign this configuration:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: sonarqube-deployment
spec:
replicas: 1
template:
metadata:
labels:
app: sonarqube
spec:
securityContext:
fsGroup: 999
containers:
- name: sonarqube
image: sonarqube:latest
ports:
- containerPort: 9000

juanledesma84 on 3 Sep 2019

if you use docker-compose
just put it in your file below's ulimits part.
in my case it works but others

  sonarqube:
    image: sonarqube
    restart: always
    ports:
      - 9000:9000
    ulimits:
      nofile:
        soft: "65536"
        hard: "65536"

cinnamond3 on 9 Sep 2019

👍6

This is how I fixed the error: max virtual memory areas vm.max_map_count [65530] is too low

In AKS deployment yaml file under sonarqube container:

env:

name: sonar.search.javaAdditionalOpts
value: -Dnode.store.allow_mmapfs=false

shawnz88 on 24 Oct 2019

👍6 🎉2

value: -Dnode.store.allow_mmapfs=false

Be careful with this approach. As mentioned in the Elasticsearch doc, disabling mmapfs will force ES to switch to another mechanism, likely niofs which is not recommended on Windows, and more generally slower.

So you may experience performance degradation by changing this. Just a point to be careful with :)

pierre-guillot-sonarsource on 4 Nov 2019

👍1

@pierre-guillot-sonarsource , how would this work with a Container hosted in Azure ACI?
It's impossible to pass environment variables with '.' (dots) in them to a container + you're also unable to change the vm.max_map_count values as you won't be able to access the host.

P.s. I don't really mind it running slower on Windows as I'm hosting a docker container on a Linux host anyway.

-Devedse

devedse on 12 Nov 2019

You can add this setting in sonar.properties in the sonar.search.javaAdditionalOpts property

pierre-guillot-sonarsource on 12 Nov 2019

👍2

@pierre-guillot-sonarsource , for that I'd have to create a custom docker image then I supose? As the ideal situation would be is that my docker image would deploy without having to first open the docker image and update the config file.

devedse on 12 Nov 2019

Well, how do you provide your db host and credentials ?

pierre-guillot-sonarsource on 12 Nov 2019

@pierre-guillot-sonarsource , I can provide them through environment variables. However within ACI it's only possible to pass those using the underscore based ones. ACI does not support '.' (dots) in environment variable names:

devedse on 12 Nov 2019

Thanks for the info. I don't see what we can do from the SQ perspective, as this env variable is related to Elasticsearch. That leave you with the solution of extending the image with a custom configuration.

pierre-guillot-sonarsource on 12 Nov 2019

@pierre-guillot-sonarsource , I also read somewhere that updating to the elastic search image version 7.3 fixes the issue. I'm not sure what has changed there though?

devedse on 12 Nov 2019

I'm not aware of that. But updating to ES7 is indeed under our radar. About your configuration file, can you bind a volume with the sonar.properties file ?

pierre-guillot-sonarsource on 12 Nov 2019

@pierre-guillot-sonarsource , that's indeed what I've just done and it seems to work. I'll post a small repo once I've gotten it all working.

devedse on 12 Nov 2019

👍1

@pierre-guillot-sonarsource , it seems the container is starting now but I'm unable to access it. It keeps loading:

Any idea what that could be?

Last log statements:

2019.11.12 16:41:48 INFO  ce[][o.s.s.p.ServerFileSystemImpl] SonarQube home: /opt/sonarqube
2019.11.12 16:41:48 INFO  ce[][o.s.c.c.CePluginRepository] Load plugins
2019.11.12 16:41:49 INFO  ce[][o.s.c.c.ComputeEngineContainerImpl] Running Community edition
2019.11.12 16:41:49 INFO  ce[][o.s.ce.app.CeServer] Compute Engine is operational
2019.11.12 16:41:50 INFO  app[][o.s.a.SchedulerImpl] Process[ce] is up
2019.11.12 16:41:50 INFO  app[][o.s.a.SchedulerImpl] SonarQube is up

devedse on 12 Nov 2019

Looks like the calls to the API are blocked. You may want to search if there is any proxy of firewall between you and the SQ instance

pierre-guillot-sonarsource on 13 Nov 2019

@pierre-guillot-sonarsource , apparently the issue was with ports being blocked @ work. I'll now deploy everything again on port 80.

Anyway, this is the script I used to deploy all this:
https://github.com/devedse/DeploySonarQubeToAzureContainerInstances

devedse on 13 Nov 2019

👍2

@oldthreefeng & @suulperi I had the same problem because the user in the container (named "sonarqube") had no write permission to the mount location on the host. I believe docker-compose was creating those directories as root. I solved it by creating those directories manually and opening up the permissions. I'll bet there's a more secure way involving making a sonarqube user on the host machine.

wrlyonsjr on 18 Nov 2019

j'ai modifié la version java de 14 à 11 et çà marche bien puisque sonarqube ne supporte pas une version plus que la version 11.

amineellouze on 4 Dec 2019

Thank you everyone.

I had to properly configure ulimits and environment on my ECS task definition(Fargate), something like:

"environment": [
    { "name" : "SONARQUBE_JDBC_URL", "value" : "jdbc:postgresql://sonarqube-db:5432/sonar" },
    { "name" : "SONARQUBE_JDBC_USERNAME", "value" : "admin" },
    { "name" : "SONARQUBE_JDBC_PASSWORD", "value" : "xxxxxx" },
    { "name" : "sonar.search.javaAdditionalOpts", "value" : "-Dnode.store.allow_mmapfs=false" }
],
"ulimits": [
    {
        "name": "nofile",
        "softLimit": 65535,
        "hardLimit": 65535
    }
],

in my case it works

chisong-yu on 30 Jun 2020

👍5

I've managed to get this started on Fargate. There were two different issues, like I've mentioned above:

I had to properly configure ulimits on my ECS task definition, something like:
"ulimits": [
  {
    "name": "nofile",
    "softLimit": 65535,
    "hardLimit": 65535
  }
]
I've disabled mmap in ElasticSearch, which gets rid of the max_map_count setting requirement. This can be done by configuring the sonar.search.javaAdditionalOpts SonarQube setting. I wasn't able to do it with an environment variable, since ECS seems to be eating them, but in the end I just passed it as a parameter to the container, which works since the entrypoint is set and consumes arguments properly. In my case:
"command": [
  "-Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmapfs=false"
]
Hopefully this information will help some people.

@Sodki Can you please share the ECS task definition JSON for reference?

javapriyan on 12 Jul 2020

While using the suggested docker-compose.yml with image: sonarqube:7.9-community, I get the following error:

db_1         | 2019-07-02 15:33:41.440 UTC [1] LOG:  database system is ready to accept connections
sonarqube_1  | 2019.07.02 15:33:41 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
sonarqube_1  | 2019.07.02 15:33:41 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
sonarqube_1  | 2019.07.02 15:33:42 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
sonarqube_1  | 2019.07.02 15:33:42 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
sonarqube_1  | 2019.07.02 15:33:42 INFO  app[][o.e.p.PluginsService] no modules loaded
sonarqube_1  | 2019.07.02 15:33:42 INFO  app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
sonarqube_1  | OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
sonarqube_1  | ERROR: [1] bootstrap checks failed
sonarqube_1  | [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
sonarqube_1  | 2019.07.02 15:33:50 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 78
sonarqube_1  | 2019.07.02 15:33:50 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
sonarqube_1  | 2019.07.02 15:33:50 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped
sonarqube_sonarqube_1 exited with code 0

However when I change the sonarqube image to sonarqube:7.7-community everything seems to work fine.

As @tmeedend mentioned, if you remove the db connection sonar.jdbc.url=jdbc:postgresql://db:5432/sonar from the env vars, even the 7.9 image runs fine.

Ubuntu 18.04.2
Docker version 18.09.6
docker-compose version 1.17.1

Thanks a Lot Its working for me too. im using sonarqube 7.9 ((latest stable version for today)) in amazon linux2 VM...

question..?
if i miss sonar.jdbc.url=jdbc:postgresql://db:5432/sonar from my properties did i miss any features in sonarqube..?

cheers

devopsarchitecture on 28 Jul 2020

This is how I fixed the error: max virtual memory areas vm.max_map_count [65530] is too low

In AKS deployment yaml file under sonarqube container:

env:

name: sonar.search.javaAdditionalOpts
value: -Dnode.store.allow_mmapfs=false

this worked for me

achomgbah on 21 Aug 2020

I am seeing the following in the log:

11:27:21 ERROR: [2] bootstrap checks failed
11:27:21 [1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
11:27:21 [2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

Guys, To everyone having this error in a recent deployment. Notice there are some changes when using 8.x image versions. as noted here https://docs.sonarqube.org/latest/setup/install-server/ in the "SonarQube 7.9.x LTS" apart.

I recommend you to add "lts" tag to the image, in order to use a 7.9 version.

Once this change is done in the dockerfile, just, re-try

jjulianprin on 16 Mar 2021

I have a similar error with the last image :
ERROR: [1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
It only occurs if I try to configure sonarqube with postgresql. If I don't touch the default config, it starts correctly with the H2 datasource.

try this:
sysctl -w vm.max_map_count=262144

as discussed here:
https://stackoverflow.com/questions/51445846/elastic-search-max-virtual-memory-areas-vm-max-map-count-65530-is-too-low-inc

this worked for me

ikomangmahendra on 15 Apr 2021

If it relies on host to run extra commands, it's not self-contained and not a container in sprit. Please try fix this without relying on host. I know it is due to elastic search but still...