I am trying to run sonar-scanner and it is hanging before the Load/download plugins. The following is the last few lines output to the screen:
12:21:38.097 INFO: Load global settings (done) | time=134ms
12:21:38.115 INFO: Server id: XXXXX-XXXXXX
12:21:38.136 DEBUG: Create : C:\Users\user1.sonar_tmp
12:21:38.137 INFO: User cache: C:\Users\user1.sonar\cache
From looking at previous logs, it appears that the following step would be next:
04:11:08.476 INFO: Load/download plugins
However, it never gets there. It just hangs. Any thoughts on how to go about troubleshooting? Without any kind of error, I am lost at where to even begin looking.
This hung in the same location, and didn’t provide any extra information (at least to the screen). Is there another location where more detailed logs are stored?
while it’s hanging, could you please get the stack trace of the process with jstack [pid_of_the_scanner_process]?
Jstack should be in your [JDK_HOME]/bin.
Sorry for the delayed response. The output of jstack is attached. I hope you can get more out of it than I can - I am not really seeing anything to indicate where to look next.
Thanks Craig.
It looks like the main thread is blocked while trying to lock a region of a temporary file, and it should not block there.
So a few questions:
a) did you wait a while before getting the stack trace, to make sure it’s hanging (and if you do it again, is it blocked at the same place?)
b) what JRE are you using?
c) is there anything special about the temporary folder in your system or is it just a regular FS?
I am using dotnet-sonarscanner to do sonar analysis on dot net core project. After running, dotnet begin > dotnet build it takes ~2hrs to build the project. If I remove the .sonarqube folder and run dotnet build directly, it finishes build execution in less than 2mins. Could you let me know what is happening here ?
Most likely no useful work is being done if you remove .sonarqube, that’s why it completes so fast.
Anyway if you could show some logs we could have a better idea about what’s going on.
To clarify my last post: running the ‘begin’ step will setup the scanner so that it hooks up to dotnet’s build. If you run dotnet directly, nothing related to the scanner is executed in the build. It’s still surprising that the scanner related build targets take 2h, but you should have an idea what’s taking so long by looking at the output of dotnet build and perhaps configuring a different log verbosity.