We are doing the 14 day free trial of SonarQube developer edition (version 10.2, installed from .zip file, on a Linux x86_64 VM). Previously I had installed the community edition, but it will not scan C and C++ files. It was working, and I was getting scan results where there were 0 of all the bad things, because of a warning that the edition did not support scanning C and C++ files.
I followed the instructions and unzipped the file to /opt/sonarqube, and I’m trying to run /opt/sonarqube/bin/linux-x86-64/sonar.sh, with the console option. It appears to run through everything completely until I keep repeatedly getting this error -
WARN es[o.e.c.r…a.DiskThresholdMonitor] high disk watermark [90%] exceeded on [RUliWBbbS9-HHmXf60YaTg][sonarqube][/opt/sonarqube/data/es8] free: 6gb[8.6%], shards will be relocated away from this node; currently relocating away shards totalling  bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete
I’ve checked the amount of memory in /proc/meminfo and it should be plenty. Not sure if this is a memory error or not. Does anyone have any idea what’s going on and how it can be fixed?
You see this warning not because of a memory problem, but because there is too little space on the disk.
So instead of proc/meminfo use a command like df -h for checking the diskspace.
Elasticsearch has several requirements, see
Free disk space is an absolute requirement. ES implements a safety mechanism to prevent the disk from being flooded with index data that locks all indices in read-only mode when a 95% disk usage watermark is reached.
Nothing individually is at 95% use. /dev/mapper/rhel-root is at 92%, but others aren’t even close.
devtmpfs (mounted on /dev) is at 0% use
tmpfs (/dev/shm) is at 1%
tmpfs (/run) is at 1%
tmpfs (/sys/fs/cgroup) is at 0%
/dev/mapper/rhel-root (/) is at 92%
/dev/mapper/rhel-home (/home) is at 6%
/dev/sda2 (/boot) is at 22%
/dev/sda1 (/boot/efi) is at 3%
tmpfs (/run/usr/42) is at 1%
tmpfs (/run/user/1000) is at 1%
Not sure how much the 92% on root would affect it, but obviously it is affecting it.
I deleted some files that were no longer needed - df still reports the rhel-root at 92%, but now I think it’s going further. And throwing out new errors. The first one is
org.elasticsearch.action.NoShardAvailableActionException: No shard available for [get [metadatas][dbVendor]: routing [null]]
ERROR web[o.s.s.p.Platform] Background initialization failed. Stopping SonarQube
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘jdk.internal.loader.ClassLoader$AppClassLoader@5ffd2b27-org.sonar.server.es.IndexCreator’: Initialization of bean failed; nested exception is 'org.sonar.server.es.ElasticsearchException: Fail to execute es requestES get request for key ‘dbVendor’ on index ‘metadatas’
and then there is another one that also references dbVendor. So I am wondering if it is not picking up the database that our community edition installation used. I downloaded and installed PostgresSQL and the community edition was executing with that. Is there a file I need to update to point it to that database? Or is this another problem entirely? I can switch databases if necessary, as long as it’s a db that doesn’t require a license (like Oracle).
No, it’s not running as root. /dev/mapper/rhel-root is just a report of what the mapper is considering part of that partition.
But anyways, I finally gave up on trying to get it running on that particular VM. I started fresh with a new VM and it’s up and running. I’ll try to see during our trial time if I can get it running on the original VM. But my suspicion is that it’s related to either having previously installed the community edition, or to not letting it use a default database. Now I’m just waiting for my license key to start the trial.