We are using Sonarqube Developer Edition deployed on Docker.
And each time we run a PR revision we get a fail status with the error Fail to execute es requestES refresh request on indices ‘issues’.
Here I leave both es and ce.log files. And the docker-compose Im using when setting everything up. I already tried some solutions that saw in the community for similar errors but this ones doesn’t look like the same issue.
docker-compose.txt (1.5 KB)
Hi,
Welcome to the community!
Have you read these logs?
What do these warnings mean to you?
2025.04.24 19:37:36 WARN es[][o.e.c.r.a.DiskThresholdMonitor] high disk watermark [90%] exceeded on [AYDmnB1ATcGQVYeEKOXaCg][sonarqube][/opt/sonarqube/data/es8] free: 728.6mb[7.3%], shards will be relocated away from this node; currently relocating away shards totalling [0] bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete 2025.04.24 19:39:06 WARN es[][o.e.c.r.a.DiskThresholdMonitor] high disk watermark [90%] exceeded on [AYDmnB1ATcGQVYeEKOXaCg][sonarqube][/opt/sonarqube/data/es8] free: 728.5mb[7.3%], shards will be relocated away from this node; currently relocating away shards totalling [0] bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete 2025.04.24 19:40:06 WARN es[][o.e.c.r.a.DiskThresholdMonitor] high disk watermark [90%] exceeded on [AYDmnB1ATcGQVYeEKOXaCg][sonarqube][/opt/sonarqube/data/es8] free: 728.5mb[7.3%], shards will be relocated away from this node; currently relocating away shards totalling [0] bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete 2025.04.24 19:41:06 WARN es[][o.e.c.r.a.DiskThresholdMonitor] high disk watermark [90%] exceeded on [AYDmnB1ATcGQVYeEKOXaCg][sonarqube][/opt/sonarqube/data/es8] free: 721.3mb[7.3%], shards will be relocated away from this node; currently relocating away shards totalling [0] bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete
Ann
Hi Ann. It was because we had few disk space left. But I already added more space and we don’t have that warning anymore, but the ElasticSearch error keeps happening.
Hi,
What error? Can you share your current es.log?
Ann
Now looks like we have a new error from yesterday but nothing at the moment of the code inspection (a few minutes ago)
On ce.log is possible to see the error org.sonar.server.es.ElasticsearchException: Fail to execute es requestES refresh request on indices 'issues'
Hi,
Your es.log indicates that Elasticsearch isn’t running. The log you posted starts with errors. What comes before that? Are you still getting the “low disk watermark” logging?
Ann
es.log (565.1 KB)
Here it’s the full log file.
No more low disk watermark after I resized the disk from the VM where the container is running.
Runs keep failing with the same error on ce.log but no new logs showing up on es.log for the last 4 days.
Hi,
Have you restarted since you resized the disk?
Ann
Yes I had to restart the VM so the resizing made effect. I just built the docker image again and now I cant see any error or warning in es.log but the error is still the same in ce.log:
ce.log (20.1 KB)
es.log (11.4 KB)
Any suggestion of what we can do? Thanks for all the help
Hi,
These two logs don’t match in terms of timestamps. es.log ends at 2025.04.28 14:14:44 INFO, while your ce.log errors don’t start until 6 minutes later: 2025.04.28 14:20:09 ERROR.
Ann
ce starts with
2025.04.28 14:13:17 INFO ce[][o.s.p.ProcessEntryPoint] Gracefully stopping process
and es starts with
2025.04.28 14:13:18 INFO es[][o.e.n.Node] stopping ...
The difference between both is only 1 second.
The es file I sent is up to date. It ends with the log:
2025.04.28 14:14:44 INFO es[][o.e.c.r.a.AllocationService] current.health="GREEN" message="Cluster health status changed from [RED] to [GREEN] (reason: [shards started [[metadatas][0]]])." previous.health="RED" reason="shards started [[metadatas][0]]"
And nothing else was logged after that, not even during the Execution of task (14:20 as you said).
Both files were downloaded from the folder:
docker exec -t sonarqube cat /opt/sonarqube/logs/es.log
Hi,
What shows up in your other logs: web.log and sonar.log?
Ann
sonar.log (4.1 KB)
web.log (15.0 KB)
Everything looks normal except from one log on web.log today at 7:44. We weren’t using the instance at that moment so I suppose is something from the image.
Hi,
So you’re saying SonarQube is up and running fine (other than the error in ce.log) but the logs (again, other than ce.log) all end at 14:14 or 14:15?
Ann
Looks like that. What would you recommend doing? Going to a previos version of the docker sonarqube:developer image?
I looked at all the issues here in the community regarding elastic search indexes error and didn’t found anything like my problem
hello @Leandro_Drazic thanks a lot for the detailed answer and info.
I have few questions regarding your installation, first we usually do not advise for docker-compose installation on production instances.
The compose files are here mostly to show-case and try out quickly our product, we would recommend to move to kubernetes for a more robust solution.
Nonetheless lets dig into the issue.
I would suggest to remove those lines:
JAVA_TOOL_OPTIONS: '-Djava.net.preferIPv6Addresses=true'
SONAR_WEB_JAVAADDITIONALOPTS: '-Djava.net.preferIPv6Addresses=true'
SONAR_ES_BOOTSTRAP_CHECKS_DISABLE: true
IPv6 has been implemented into SonarQube code, but not into the docker images yet (we still have hard dependencies on IPv4)
For the bootstrap_checks, this is an Elasticsearch safety mechanism to make sure the vm/container is setup correctly to run ES. Hence deactivating might hide problems.
On top of that if you experienced issues with ES indices, one thing we can try is cleaning up elasticsearch and sonarqube container data with a command like:
docker-compose down sonarqube -v
This will prune sonarqube volumes. Please note that this command might delete the database data if the db container is not running.
If you are unsure of what you do, please let me know i can write down a more detailed set of command to ensure data integrity.
Cheers,
Jérémy.
Thanks Jeremy!
Removing those lines, and running docker-compose down sonarqube -v fixed our issue.
I don´t know the reason why we were having that error, because that lines were added in base of other recommendations for ES errors in other posts.
Maybe something was fixed on 6th May release?
Anyway, thanks for the help 