Sonarqube is getting stopped every one month once

Must-share information (formatted with Markdown):

  • which versions are you using (9.9 LTS)
  • how is SonarQube deployed: zip
  • what are you trying to achieve
  • what have you tried so far to achieve this

Hi Team,

Sonarqube application is getting stopped once in a month with below error. Although I have set vm.max_map_count and other details which mentioned below. And also added below lines in /etc/sysctl.d/99-sonarqube.conf as well.
sysctl -w vm.max_map_count=524288
sysctl -w fs.file-max=131072
ulimit -n 131072
ulimit -u 8192

I am running sonarqube with user account only not with root. Please let us know what i can do to resolve this issue. So that it should not happen again in future.

=================================================================
ERROR: [1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch.
bootstrap check failure [1] of [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
ERROR: Elasticsearch did not exit normally - check the logs at /apps/sonarqube/sonarqube-9.9.1.69595/logs/sonarqube.log
2023.11.20 01:16:24 WARN app[o.s.a.p.AbstractManagedProcess] Process exited with exit value [ElasticSearch]: 78
2023.11.20 01:16:24 INFO app[o.s.a.SchedulerImpl] Process[ElasticSearch] is stopped
2023.11.20 01:16:24 INFO app[o.s.a.SchedulerImpl] SonarQube is stopped

Hi,

What happens after the stop? I guess you readjust vm.max_map_count?

This system setting is not something SonarQube can or does adjust. My guess is that you have an external process automatically resetting your OS to “normal” once a month, which is what causes this. You should talk to your Ops and/or security folks.

 
HTH,
Ann

Hi @ganncamp

There was a monthly patching scheduled for the sonarqube servers. Due to this vm.max_map_count is going less than the expected.

Sonarqube is going down monthly due to this. So,do we have any solution for this to fix permanently after patching.

Hi,

The solution would be on your side to update your patching script to put vm.max_map_count back where it should be.

 
HTH,
Ann