SQ Developer Edition failing to startup on new server

Hi y’all,
Before purchasing a Developer’s License for SonarQube, my company spent 2 weeks with a trial key that we spun up on an on-prem server. Once we were satisfied with the results SonarQube was giving us, we purchased the full license and started the process of getting it set up on a brand new Azure Virtual Machine dedicated solely for SonarQube, its database, and the scanner. Despite following the same steps we followed when setting up the trial key (and before that, the community edition), we are unable to get SonarQube to spin up fully.

A standard console log from the command prompt after running the StartSonar command is:

--> Wrapper Started as Console
Launching a JVM...
Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
  Copyright 1999-2006 Tanuki Software, Inc.  All Rights Reserved.

2021.12.17 15:21:31 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory C:\Users\kp\Desktop\sonarqube\..\SonarQube_Data\temp
2021.12.17 15:21:31 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on [HTTP:, TCP:]
2021.12.17 15:21:32 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [C:\Users\kp\Desktop\sonarqube\elasticsearch]: C:\Program Files\Java\jdk-11.0.12\bin\java -XX:+UseG1GC -Djava.io.tmpdir=C:\Users\kp\Desktop\sonarqube\..\SonarQube_Data\temp -XX:ErrorFile=../logs/es_hs_err_pid%p.log -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dio.netty.allocator.numDirectArenas=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Djava.locale.providers=COMPAT -Dcom.redhat.fips=false -Des.enforce.bootstrap.checks=true -Xmx512m -Xms512m -XX:MaxDirectMemorySize=256m -XX:+HeapDumpOnOutOfMemoryError -Delasticsearch -Des.path.home=C:\Users\kp\Desktop\sonarqube\elasticsearch -Des.path.conf=C:\Users\kp\Desktop\sonarqube\..\SonarQube_Data\temp\conf\es -cp lib/* org.elasticsearch.bootstrap.Elasticsearch
2021.12.17 15:21:32 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2021.12.17 15:21:51 INFO  app[][o.s.a.SchedulerImpl] Process[es] is up
2021.12.17 15:21:51 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[[key='web', ipcIndex=2, logFilenamePrefix=web]] from [C:\Users\kp\Desktop\sonarqube]: C:\Program Files\Java\jdk-11.0.12\bin\java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=C:\Users\kp\Desktop\sonarqube\..\SonarQube_Data\temp -XX:-OmitStackTraceInFastThrow --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED --add-exports=java.base/jdk.internal.ref=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-opens=java.management/sun.management=ALL-UNNAMED --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED -Dcom.redhat.fips=false -Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError -Dhttp.nonProxyHosts=localhost|127.*|[::1] -cp ./lib/sonar-application-;C:\Users\kp\Desktop\sonarqube\lib\jdbc\mssql\mssql-jdbc-9.2.0.jre11.jar org.sonar.server.app.WebServer C:\Users\kp\Desktop\sonarqube\..\SonarQube_Data\temp\sq-process11783157654702250184properties

Before on the on-prem server and before locally with the community edition, simply using StartSonar would have the system take about 10 seconds to boot up and open sonarqube in localhost, but now after printing the “Launch Process [key=‘web’]” line, the startup just hangs until it is Ctrl-C trapped and shutdown ungracefully. Is there something simple we’re missing here (such as, more resources dedicated for it in the Virtual Machine’s settings?)

We’d appreciate any amount of help here!
Thank you!

Hi @jcrimi,

Welcome to the Community! :smiley:

The first place to check for more information about what’s going on is the log files. I’d suggest <SONARQUBE_HOME>/logs/web.log and <SONARQUBE_HOME>/logs/sonar.[date].log as starting points. Let me know if you find something suspicious there.



Sorry for the delayed response here but I do really appreciate the response!
We took a look at the logs and found that reason why it’s not able to spin up the Web process is because it could not connect to our SQL server (which we are using SQL Auth to connect to).
We took a look through the sonar.properties file in the conf folder and tried a few things, but none of them seemed to work. The related lines we have uncommented are the following:

sonar.jdbc.password=[Our Password]


The error that we have been getting is:

The TCP/IP connection to the host localhost, port 1433 has failed. Error: "Connection refused: connect. Verify the connection properties. Make sure that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port. Make sure that TCP connections to the port are not blocked by a firewall."

I can use the username and credentials from the properties file to connect to the db manually, but for some reason SonarQube just does not want to connect through and we cannot figure out why.

We also found out that during our testing phase with the SonarQube trial, we’d actually never successfully connected to the database and it’d always just been using the embedded H2 database, which explains why following the steps we followed for the trial did not work.

Hi Joe,

Thanks for the extra information. This looks like a TCP connectivity issue, which is odd given the host and database are on the same machine. There are a couple of possibilities here – you may have checked some of this already, but here goes:

  • Is SQL Server actually listening on port 1433? I know this is its default port, but has that been changed in your SQL Server setup?
  • Can you telnet from a shell window to localhost:1433?
  • Is there a firewall or some antivirus software that might be blocking particular ports? (Unlikely if you’ve been able to connect to the db manually)



1 Like

Thanks so much for your insight Cameron!!

Turns out, the SQLServer was never actually listening on any TCP ports at all, so enabling that & telnet allowed us to spin up SonarQube the way we wanted.

1 Like

Glad to hear you got it working, Joe! :smiley:



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