I know this is similar to sonarqube 5.2 background tasks sometimes fail with no log - however I cannot comment (due to lack of reputation points) to add some more information, so tried adding this post as an answer, but had it deleted by the moderators...
I was having a problem with SonarQube 5.2
, and now 5.3 following an upgrade yesterday. I have tried upping the logging to TRACE on the server, and enabling sonar.verbose=true on the project itself.
However, there is no extra information in the output from the maven build - just the normal:
ANALYSIS SUCCESSFUL, you can browse xxx in the build logs.
I do see a POST /api/ce/submit?projectKey=xxxx&projectName=yyyy | time=757ms
in the server log files - but nothing further.
I also see a zip file in data\ce\reports
with a name matches the id in build log (eg: AVI19fDPpe3MLWoccJn9.zip)
However - I get intermittent failures on the background tasks screen - with no log link in the background tasks screen, and no logs in data\ce\logs\reports
directory created.
I resorted to re-building the sonarqube database from scratch for 5.3 (as we had no history anyway) - and the error was still happening.
I am using:
- Oracle DB on a fresh
sonarqube 5.3
install - Plugins:
- sonar-java-plugin-3.9
- sonar-ldap-plugin-1.5.1
- sonar-scm-perforce-plugin-1.3 (although currently have
sonar.scm.disabled=true
as we had problems in the previous version) - sonar-csharp-plugin-4.3 (not relevant for this java analysis)
- sonar-scm-git-plugin-1.1 (not relevant for this analysis)
- sonar-scm-svn-plugin-1.2 (not relevant for this analysis)
- I'm building a Maven project using
sonar-jacoco-listeners v 3.2
(have also tried 2.9.1)
You are facing a very odd issue.
To sum it up:
data/ce/logs
directoryThe only time we faced such a scenario, it turned out two SonarQube instances were running on the same database and here is what was going on:
A good hint that the processing (ie. change of state of the entry in DB) wasn't done by the SQ A is that the report zip file is still present in the data directory. The change of state of the entry to FAIL or SUCCESS is tightly coupled with the deletion of the zip file.
It's only a hint since the deletion could also have failed, but in such case, you would have a ERROR in the logs.