[Sonarqube] Issues in upgrading sonarqube from 8.9.4 to 9.9.5 LTS

[Alok650]

Describe your issue as much as you can

Hi team
We currently use bitnami sonarqube - setup inside a aws EC2 built using bitnami sonarqube ami. We are trying to upgrade the existing sonarqube in EC2 from 8.9.4 (current version supported by the ami itself) to 9.9.4 (the next LTS).

Currently we have two approaches:

1. Setup a new sonarqube using 9.9.4 AMI and then migrate the Postgres db data into the new server. However this requires downtime and also there are issues while migrating the Postgres data (using pgdump) due to change in Postgres version.

2. Use the existing EC2 setup. Install java 17 (currently it's using java11). Download sonarqube 9.9.4 as a zip file and replace existing sonarqube folder inside bitnami folder to use the new sonarqube (9.9.4) and restart the bitnami service. We tried this approach, but sonarqube fails to come up (exit code 1).
   Journalctl logs show:

INFO ## Running /opt/bitnami/var/init/pre-start/060_get_default_passwords...
## 2024-06-19 14:35:54+00:00 ## INFO ## Starting services...
2024-06-19T14:35:55.612Z - info: Saving configuration info to disk
2024-06-19T14:35:55.989Z - info: Performing service start operation for postgresql
postgresql 14:35:56.30 INFO  ==> postgresql is already running
2024-06-19T14:35:56.306Z - info: Performing service start operation for apache
apache 14:35:56.57 INFO  ==> apache is already running
2024-06-19T14:35:56.578Z - info: Performing service start operation for sonarqube
sonarqube 14:36:57.11 ERROR ==> sonarqube did not start
2024-06-19T14:36:57.120Z - error: Unable to perform start operation Export start for sonarqube failed with exit code 1
## 2024-06-19 14:36:57+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/010_bitnami_agent_extra...
## 2024-06-19 14:36:57+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/020_bitnami_agent...
## 2024-06-19 14:36:57+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/030_update_welcome_file...
## 2024-06-19 14:36:57+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/040_bitnami_credentials_file...
## 2024-06-19 14:36:57+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/050_clean_metadata...
systemd[1]: bitnami.service: Control process exited, code=exited, status=1/FAILURE

Please help in what will be the optimal way to upgrade the existing sonarqube setup with minimum downtime.

[Alok650]

@gregory109 I tried updating the whole /opt folder itself, which includes Java and sonarqube, but it failed. will try with just java and sonarqube folders inside /opt. Also in my current ami I have two folders i.e. stack (at ~) and /opt/bitnami - both contain the same content i.e. sonarqube, java, apache and other components required. Why is this duplicity there?

Also the logs folder inside sonraqube is empty when I restart bitnami and sonarqube fails. Any other place to get specific logs?

[Alok650]

@gregory109 I attempted the second approach. currently sonarqube fails to restart. These are the logs inside sonar.log:

2024.06.24 11:11:10 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/bitnami/sonarqube/temp
2024.06.24 11:11:10 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on [HTTP: 127.0.0.1:9001, TCP: 127.0.0.1:39701]
2024.06.24 11:11:11 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[ELASTICSEARCH] from [/opt/bitnami/sonarqube/elasticsearch]: /opt/bitnami/sonarqube/elasticsearch/bin/elasticsearch
2024.06.24 11:11:11 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2024.06.24 11:11:12 INFO  app[][o.s.a.SchedulerImpl] Process[es] is up
2024.06.24 11:11:12 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[WEB_SERVER] from [/opt/bitnami/sonarqube]: /opt/bitnami/java/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/opt/bitnami/sonarqube/temp -XX:-OmitStackTraceInFastThrow --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED --add-exports=java.base/jdk.internal.ref=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.management/sun.management=ALL-UNNAMED --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED -Dcom.redhat.fips=false -Xmx971m -Xms388m -XX:+HeapDumpOnOutOfMemoryError -Dhttp.nonProxyHosts=localhost|127.*|[::1] -cp ./lib/sonar-application-9.9.5.90363.jar:/opt/bitnami/sonarqube/lib/jdbc/postgresql/postgresql-42.5.1.jar org.sonar.server.app.WebServer /opt/bitnami/sonarqube/temp/sq-process16879507935916711793properties
2024.06.24 11:11:13 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [Web Server]: 1
2024.06.24 11:11:13 INFO  app[][o.s.a.SchedulerImpl] Process[Web Server] is stopped
2024.06.24 11:11:13 INFO  app[][o.s.a.SchedulerImpl] Process[ElasticSearch] is stopped
2024.06.24 11:11:13 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [ElasticSearch]: 143
2024.06.24 11:11:13 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped

[jotamartos]

Setup a new sonarqube using 9.9.4 AMI and then migrate the Postgres db data into the new server. However this requires downtime and also there are issues while migrating the Postgres data (using pgdump) due to change in Postgres version.

You can try migrating the information and see if the new version works as expected. That may be a first step. You can later work on migrating your domain to the new site, the only downtime would be this migration of the domain.

https://docs.bitnami.com/general/apps/sonarqube/administration/upgrade/

[gitricko]

How about thinking a different way... instead of hosting a central sonarqube... why don't install a brand new sonarqube, scan it... and download the metric file result for checking the measure that u need to pass/fail

If you need example: check out https://github.com/gitricko/sonarless .. it has a GHA for it too

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.