SonarQube Console only shows "Loading..." with no log errors

Hello,

I have been trying to set up SonarQube on my CentOS-7 box and I can’t get the console to come up after running ‘sonar.sh console’. I went through all the setup procedures, including installing and configuring ElasticSearch, which is running in a Docker container, and there are no errors in any of the logs. I have a few warnings in the web.log referring to a response example not being set on API actions, but no errors, however, when I turn on the DEBUG flag in the config file I get several connection refused messages for http://127.0.0.1:9001. I’ve tried turning the firewall off, ‘nmap localhost’ shows ports 9000 and 9001 open for tcp connections, and netstat shows an established connection on port 9001, so it doesn’t appear that I need to configure my network to open up this port. Any ideas?

Here is my configuration:

CentOS-7 64-bit
16GB RAM, 200GB storage, 4x CPUs
Firefox v52.7.0
URL: localhost:9000
SonarQube 9.0.0.45539
OpenJDK 18.9 (build 11.0.11+9-LTS)
Java 11.0.11.0.9-1.el7_9.x86_64
vm.max_map_count=262144
ulimit -n 65535
ulimit -u 4096
ElasticSearch running as a single node via the following command:

docker run -p 9200:9200 -p 9300:9300 -e “discovery.type=single-node” docker.elastic.co/elasticsearch/elasticsearch:7.13.3

Process[ce] is up
SonarQube is up
sonar.web.host=localhost
sonar.web.port-9000
sonar.web.http.maxThreads=50
sonar.web.http.minThreads=5
sonar.web.http.acceptCount=25
sonar.web.sso.enable=false
sonar.web.sso.loginHeader=X-Forwarded-Login
sonar.web.sso.nameHeader=X-Forwarded-Name
sonar.web.sso.emailHeader=X-Forwarded-Groups
sonar.ce.javaOpts=Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError
sonar.ce.javaAdditionalOpts=
sonar.search.javaOpts=-Xmx512m -Xms512m -XX:MaxDirectMemorySizez=256m -XX:+HeapDumpOnOutOfMemoryError
sonar.search.javaAdditionalOpts=
sonar.search.port=9001
sonar.search.host=localhost

One DEBUG message I’m seeing is:

DEBUG app[o.e.c.RestClient] updated [[host=http://127.0.0.1:9001]] already in blacklist

Solved! SonarQube 9-community is broken. Once I run any 8.x version, it works.

Hi @linuxguy and welcome to the community :wave:

can you elaborate on this?

if there is something utterly broken for you it would be nice for us to understand in order to fix it in a future version of SQ :slight_smile:
apart from that i am a bit confused why you are starting an additional elasticsearch container. elasticsearch is bundled with SQ in CE/DE/EE so these editions should not be able to connect to an external elasticsearch. in general you can find more information about what has actually failed in the logs directory of your SQ installation.

See my first post. There’s a whole lot of details to my problems, which I posted 3 days ago, and until I fixed it myself by using an older version and subsequently marked this issue as ‘fixed’, all I heard were crickets.

I started an additional elasticsearch container b/c v9.0 doesn’t work straight out of the box and I was grasping at straws. I analyzed the logs you are referring to at great length. Again, something you would know if you read my first post…or even the title of this thread.

please note that this is a community forum where people from inside and outside sonarsource are helping users in their spare time. this is also stated in the FAQ.

i have read your first post and there are still things that are not clear to me, like how do you start sonarqube in the first place. we document multiple ways to start sonarqube and not all of them work with sonar.sh console. as you are on centos7 you could also start SQ with systemd where the wrapper would not matter anymore.
other information like the load of your system and users could also have an impact that the console log is not printed. also the consolte log of the wrapper is not expected to print much after it has launched the sonar-application java process.

Other information that i am also missing from your first post is if SQ is reachable on port 9000 or if any java processes are running. i can assume that it does from the fact that you have a open 9000 port from your nmap scan, but this would be nice to understand what you are actually trying to do.

hope you see my point here. i would really like to understand what went wrong on your deployment but i am not even understanding from your post IF something went actually wrong or you are just facing a unintuitive expected behavior

Hi,

same here with upgrade from enterprise edition 9.1.0.47736 to 9.2.0.49834

I open a ticket to support.
Best regards