SonarQube server inaccesible after version upgrade while service is running

SonarQube Server / Community Build
, ,
1

We are currently using SonarQube Community Edition v8.0 and recently tried to upgrade to v8.6.1.

As mentioned in the documentation, we took a dump of our postgres db, reconfigured the properties.conf file accordingly and finally performed the upgrade with no issue.

However, a few hours later the SonarQube server started showing up as unavailable and in the logs we were receiving an error that the Elastic Search limits were too low. We thus increased the limits, rebooted our vm and re-ran the sonar.sh script. We were now receiving no error in our logs, the SonarQube service status showed that it was successfully running, but when we were trying to connect through the web or publish a sonar analysis, we were receiving a Connection Timed Out and Server Unreachable accordingly.

What we’ve tried to resolve the issue but did not work:

  • Make sure we were executing the sonar.sh script as sonar user and not as root.
  • Set: sonar.web.host and sonar.web.port properties with the correct values.
  • Set proper limits for: LimitNOFILE, LimitNPROC, elasticsearch, vm.max_map_count, fs.file-max.
  • Perform a VACUUM FULL on our db, just in case it was slowing down the server.
  • We are using a reverse proxy so we also set: setsebool -P httpd_can_network_connect 1.

Can anyone point us to the right direction about where we went wrong?

As previously mentioned, no errors showed up on our logs to guide us, everything seemed to be running smoothly, but the SonarQube server was inaccessible.

Thank you

2

Hey there.

We are currently using SonarQube Community Edition v8.0 and recently tried to upgrade to v8.6.1 .

First, there’s no version you should target except the latest version, v8.8 :slight_smile: When running a non-LTS version, only the very latest version is supported.

The behavior you describe sounds pretty weird (the check on Elasticsearch limits should have kicked in well before your upgrade completed successfully) – I would double-check you don’t have two SonarQube instances (perhaps your old install directory and new one?) trying to speak to the same database.

After that, I would suggest performing a simple curl from on your server (localhost) to find out if the issue is with your SonarQube instance, or might instead be with the reverse proxy sitting in front of your Sonarqube server. Something like the following, adjusted for whatever port you are using. For example:

curl localhost:9000/api/system/status