I’ve tried to run SonarQube for the first time following the sonarqube doc.
While I fixed the typical problems on my own (wrong pathes, no database connection…) hinted by the log files I’m stuck now and need help.
Whenever I start SonarQube it’s stopped immediately. While there is no error on the console the web.log file contains a single warning but no error:
WARN web[][o.a.c.l.WebappClassLoaderBase] The web application [ROOT] appears to have started a thread named [SQ starter] but has failed to stop it. This is very likely to create a memory leak.
On the first run the database was set up successfully but afterwards SonarQube just stops.
Attached are the log files for further investigation.
Hopefully someone has a hint for me how to proceed.
edit: I’ve downloaded SonarQube 7.8. and it runs without any issues… so it seems to be a bug in the current LTS version
thanks for your reply.
I’ve changed my log.level to DEBUG and database back to Embedded Database (default) for debugging purposes as well.
Still the same problem, see logs attached.
Thanks for the debug logs. As I’m sure you’re already aware, there’s not much more in these than there was in the first batch.
From the timestamps, it looks like ES is shutting down first (this is a little bit of a guess) and the other nodes shut down in response. The thing that can make ES shut itself down is inadequate system resources: filespace, file descriptors, … However in that case, it would be reflected in the logs. Still, it’s worth checking the minimums laid out in the Linux Platform notes. It’s also worth checking your free disk space. Again, if it were too low I would expect that to show up in the logs, but I’m grasping at straws.
Once we’ve eliminated all the internal factors that could be causing this shutdown, I think we have to look external to SonarQube; is there any process on your box that could be protectively killing the ES process because it’s grabbing ports and the process doesn’t think it should be?
whereas the m.max_map_count and file descriptors needed to be increased during installation.
Free disk space is ~60GB
If the reason would be an inadequate system or another process that kills the ES: Why is sonarQube 7.8 running without any issue?
As far as I know 7.8 contains ES as well, right?
For now I’m fine and happy with running 7.8, but maybe we can figure out what the reason is to prevent other users having the same problem(s).
I’ve looked into the information provided in this thread and the logs attached.
My opinion is that the WebServer is shutting down very quickly while it is still starting up (and ES is only following). As mentioned before, there is no visible cause in the logs (the one stacktrace is only a consequence of the premature shutdown).
What I can’t tell from the logs, is whether the shutdown occurs for reasons internal to the WebServer (bug or whatever) or an external reason (eg. process being killed).
If you could give a try with TRACE log level, we would get confirmation on that.
Also, I noted that in the second batch of logs (the DEBUG ones) SonarQube connected to a H2 database while in the first one it was a Postgres Database. This seem to indicate that the DB is out of the problem.
I think the cause of the failure to start is the following error (which Tomcat displays only when TRACE is enabled, apparently):
2019.10.18 09:40:31 ERROR web[][o.a.c.c.C.[.[.[/]] Exception starting filter [WebPagesFilter]
java.lang.IllegalStateException: Fail to load file /index.html
at org.sonar.server.platform.web.WebPagesCache.loadHtmlFile(WebPagesCache.java:110)
at org.sonar.server.platform.web.WebPagesCache.provide(WebPagesCache.java:98)
at org.sonar.server.platform.web.WebPagesCache.lambda$generate$0(WebPagesCache.java:91)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at org.sonar.server.platform.web.WebPagesCache.generate(WebPagesCache.java:91)
at org.sonar.server.platform.web.WebPagesCache.init(WebPagesCache.java:72)
at org.sonar.server.platform.web.WebPagesFilter.init(WebPagesFilter.java:69)
at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:285)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:266)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:108)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4662)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5309)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1423)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1413)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.NullPointerException: null
at java.base/java.util.Objects.requireNonNull(Objects.java:221)
at org.sonar.server.platform.web.WebPagesCache.loadHtmlFile(WebPagesCache.java:103)
... 18 common frames omitted
Can you verify the file [sonarqube_home]/web/index.html exists and is accessible by the process running SonarQube?
thx @sns-seb that was it… I’ve checked if the file exists and it dit not.
So I started to investitgating why: Seems it was an issue while moving the sonarqube directory after unpacking it.
At the old location there was (only) the index.html left. Don’t know why it wasn’t moved with the other files.
I’ve moved it as well and now it works… really thx a lot and a big sorry that the problem was on my side.
)