Clean Analysis Reports after Moving 9.9.1 LTS Developer to New Server

SonarQube: Developer
Database: PostgreSQL 12.14
SonarQube is deployed using Docker via docker-compose

I moved my server from a VM running CentOS 7 to and Openstack setup running Rocky Linux 8. I moved the database using:

docker exec -t IMAGE_ID pg_dump -c -U sonar > sonar.sql

to backup and

cat sonar.sql | docker exec -i IMAGE_ID psql -U sonar

to restore.

After moving, all of my C++ analyses are coming up clean, but this shouldn’t be true.

The scan logs don’t indicate any issues, and I’m not sure what to check next.

Any suggestions appreciated.

I’m noticing that the rules in the Sonar way C++ are labeled Inactive.

Does this mean they are not being used (if so, how do I fix this), or does it mean the scan didn’t find a violation of that particular rule (which shouldn’t be true)?

I believe this was cause by a licensing issue. When the new server was first setup, new system information was sent to get an updated license. After the license was obtained, the data base was moved from the old to new servers and the FQDN was updated on the new to match the old and was removed from the old. Then the system information on the new changes to match what was on the old. This cause quality profiles to not be grabbed or updated. At least that’s my current guess. SonarSource is in the process of sending me the proper license info and updating my info on their side.

Sorry for the noise.

Well, I take it back. After obtaining a new license key, I’m still in a situation where all of the rules an all of the Quality Profiles are inactive. I’m totally stumped.


It’s not clear to me whether you moved only where the database lives or also where SonarQube lives. If the latter, then the problem may be bad Elasticsearch indices.

Can you dump them and restart the server so they’ll re-generate?


1 Like

Thank you for your reply!

I moved the server from a VMware VM running CentOS 7 to an Openstack instance running Rocky Linux 8. I’m using docker compose to run the server, so the base OS isn’t critical. The move was made to prepare for the eventual EOL of CentOS in 2024.

So once I had the Developer edition up and running on the new server, I migrated the database using the commands in my original post. After that I realized the server ID had changed and requested a new license key and applied it.

Then our IT folks applied a CNAME that was associated with the old server to the new one and the server ID changed back to the one that was originally on the old server. I requested a new key, applied it and everything seemed to work except the activation of the builtin Sonar way rules, so everything was coming back clean.

I do not see a populated Elasticsearch database on the new server:

$ docker run --rm --entrypoint ls mysonarqube-9.9.1 data

I should also mention that my GitLab server that the SonarQube server works with is in another building and is connected using encryption. Initially the two boxes were not able to communicate due to dropped packets. Our IT department resolved this by lowering the MTU size used in the network connections in the docker-compose.yml file.

I’m wondering if the new server is not able to communicate with SonarSource to grab analysis rules updated or I fouled up entering the license key or …?

I temporarily went back to running off the old server until we can figure out what is up with the new one.

Thanks for the help!


This wouldn’t be about your license key or dropped packets - the UI is showing 0 rules too.

As a side note, when you run a commercial edition without a valid license everything in the UI works; you just can’t run new analyses. So even with a bad license, you should still see rules active in the Sonar way C++ profile.

So let’s come back to Elasticsearch. Your server wouldn’t be running if ES hadn’t been able to find/create its indices somewhere. Can you please track them down, delete them and bounce the server to see if the numbers populate correctly?


Thanks. Let me start up the new server and see if I can find the ES data.

1 Like

That was it! Thank you!

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.