search

SonarSource / docker-sonarqube

:whale: SonarQube in Docker
https://hub.docker.com/_/sonarqube/
GNU Lesser General Public License v3.0
1.37k stars 1.02k forks source link

Sonarqube crashed still with latest image #282

Closed leeadh closed 5 years ago

leeadh commented 5 years ago

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

image

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 ?

Aypahyo commented 5 years ago

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

wburgers commented 5 years ago

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]

tmeedend commented 5 years ago

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.

senart commented 5 years ago

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.

bdavis-tc commented 5 years ago

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

senart commented 5 years ago

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

marta1213 commented 5 years ago

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

Best Regards,

senart commented 5 years ago

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

Sodki commented 5 years ago

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
[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]```
Aypahyo commented 5 years ago

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?

Sodki commented 5 years ago

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

  1. I had to properly configure ulimits on my ECS task definition, something like:
"ulimits": [
  {
    "name": "nofile",
    "softLimit": 65535,
    "hardLimit": 65535
  }
]
  1. 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.

oldthreefeng commented 5 years ago 
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

Sodki commented 5 years ago

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

suulperi commented 5 years ago

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.

ghost commented 5 years ago

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 :

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

shacharaj commented 5 years ago

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:

  1. 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
  1. sudo sysctl -w vm.max_map_count=262144
  2. 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:
suulperi commented 5 years ago

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
ghost commented 5 years ago

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

docker cp CONTAINER_ID:/opt/sonarqube/logs .

suulperi commented 5 years ago

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
ghost commented 5 years ago

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

suulperi commented 5 years ago

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
ghost commented 5 years ago

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

suulperi commented 5 years ago 
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

  1. 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
  2. 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
ghost commented 5 years ago

What is the content of your volume sonarqube-conf?

suulperi commented 5 years ago 

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
´´´
oldthreefeng commented 5 years ago

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.

suulperi commented 5 years ago

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

securityContext:
   fsGroup: 999
ardevd commented 5 years ago

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]

ghost commented 5 years ago

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

ardevd commented 5 years ago

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

ardevd commented 5 years ago

removing and recreating the docker container resolved the issue.

pascallalonde commented 5 years ago

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.

ghost commented 5 years ago

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.

regentov commented 5 years ago 
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 ...
juanledesma84 commented 5 years ago

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:

cinnamond3 commented 5 years ago

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"
shawnz88 commented 4 years ago

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:

ghost commented 4 years ago
  • 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 :)

devedse commented 4 years ago

@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

ghost commented 4 years ago

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

devedse commented 4 years ago

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

ghost commented 4 years ago

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

devedse commented 4 years ago

@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:

image

ghost commented 4 years ago

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.

devedse commented 4 years ago

@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?

ghost commented 4 years ago

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 ?

devedse commented 4 years ago

@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 commented 4 years ago

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

image

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
ghost commented 4 years ago

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

devedse commented 4 years ago

@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