I’m using SonarQube Developer 9.3.0, installed via Docker - using docker-compose.yml according to the example in documentation. Then, we’re booting it up with docker-compose up -d
I’ve been having issues updating it. There is information about it in documentation, but it explains only manual stoping/removing the container, etc. As there are no additional notes about docker compose, I thought just swapping Docker image tags in docker-compose file and executing again docker-compose up -d would be sufficient - according to the Docker Documentation, that would essentially do the same thing:
If there are existing containers for a service, and the service’s configuration or image was changed after the container’s creation, docker-compose up picks up the changes by stopping and recreating the containers (preserving mounted volumes).
This method worked first few times without any issues, but yesterday I ended up with completely ruined / damaged database indexes and SonarQube was not able to start… Logs showed tons of error stack trace, but the main exception I guess is this:
failed to merge org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)
Luckily we’ve created a snapshot earlier, so we could just roll back to the previous VM state and not even tried to fix the issue (as we already had once issue with db indexes being destroyed just by rebooting VM).
Can someone explain me what could be the problem in my approach or what should be the proper way to update SonarQube? This is already 2nd time in 4 months I’ve managed to destroy the db
Unfortunately, I cannot tell, as I used the VM snapshot to immediately reverse to the previous (working) state.
Could you please tell me if the way I update SonarQube is ok, or is there another preferred way to update?
Hi, I have the same problem. I also use Docker-Compose to host Sonarqube and wanted to update the containers today. The Sonarqube container sonarqube:community built 6 days ago doesn’t start anymore and gives the error: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?) The error is also thrown by the ElasticSearch database as described here, so I already tried to delete the directory es7 in the data volume of the container so that this is recreated on startup. Unfortunately this does not solve the problem. Are there any other things I can try? If you want, I can post the whole stacktrace here.
In my post I only referenced the latest alpine version. The SonarQube docker is on the 3.14 line, so for our docker of SonarQube I’ve been using 3.14.2 to be consistent with what SonarQube has been using. No reason to believe this would be any different then 3.15.2 for SonarQube, but going with what they’ve tested.
So any alpine version after (and including) these you may have some Zip CRC issues, or issues with elastic search checksums it seems:
So, looks like the root of the problem is updated zlib library to v1.2.12 in the alpine images, which changes are then reflected in rebuilt docker images of sonarqube?
I am also running Sonarqube via Docker inside a VM on a Proxmox server - suggested solution is to change the CPU type to Haswell - does anyone know what are consequences of this? I am also running some other services on the same VM at the moment… Is this indeed an intended behavior from zlib or should this be fixed from their side for kvm64 CPU architecture type?
Hi looks like this will be fixed in a newer version of the SonarQube docker when they update alpine or if they force updating of zlib. The alpine folks have updated ZLib to include a patch for this issue and pushed to the 3.15 repo and I can confirm it works.
So to do this you simply copy paste the SonarQube Dockerfile, upgrade alpine to 3.15.4, then add this command: RUN apk upgrade zlib