sonarScanner hangs

The scan starts but at some point only empty INFO lines are printed to the console.

11:25:27.456 INFO: Indexing files...
11:25:27.457 INFO: Project configuration:
11:25:27.458 INFO:   Excluded sources: gen/protobuf/**
11:25:27.521 DEBUG: loading config FileBasedConfig[/root/.config/jgit/config]
11:25:27.522 DEBUG: readpipe [/usr/bin/git, --version],/usr/bin
11:25:37.457 INFO: 
11:25:47.458 INFO: 
11:25:57.458 INFO: 
11:26:07.458 INFO: 
11:26:17.459 INFO:

I must admit, that I don’t have a /root/.config/
Could it be, that for some reason git is not found?
It is installed:

/usr/bin # /usr/bin/git --version
git version 2.30.6

Thanks a lot, Thorsten

Hey there.

What version of SonarQube are you using (it should be in the footer of your SonarQube instance).

Hi Colin,

it is :
Enterprise Edition - Version 9.5 (build 56709)

Are there any more logs produced, other than what sonar-scanner is printing to console?
If yes, where can I find them?

There are a number of changes related to Git in the versions leading up to SonarQube v9.9 LTS.

SonarQube v9.5 has been EOL since SonarQube v9.6 was released, so I suggest upgrading to SonarQube v9.9 LTS and letting us know if you still face the issue!

It looks like you already have DEBUG logging turned, so there’s no further logging available.

I’m not quite sure, if it is at all related to git.
I remove the line completly from file.

And still the issue is the same.
Updating the SonarQube to 9.9 is somewhat difficult because there are plenty of other projects affected.

I also don’t understand, how the version of SonarQube on the server affects the behavior of the sonar-scanner on the client side.
What is the scanner about to do after the line

Could it be because of I’m running the Java version on Alpine Linux on arm architecture (aarch64) ???

All other project (that are using the same SonarQube V9.5 Server) are performing fine.
One difference is, that only the problematic project is performing the scan on an ARM machine.

Hey there.

It could be.

As I mentioned, it would be best to see if you can reproduce the error on a supported version (v9.9 LTS), even if it’s just a test version, to see if the behavior can be reproduced.