The host lorenzo.hjemme.lan is a machine in my LAN, with DNS name and DHCP handlet by my LAN router. Ping lorenzo.hjemme.lan works and curl and web browsers work perfectly well with the URL http://lorenzo.hjemme.lan:9900/projects
(and anyway I have what looks like the same problem on github actions and sonarcloud…)
What I have tried that didn’t make any difference:
check ~/.m2/settings.xml for proxy settings (there weren’t any)
verify that I don’t have any http proxy environment variables set
Tried enforcing IPv4 with -Djava.net.preferIPv4Stack=true
Tried enforcincg DNS usage with -Dsun.net.spi.nameservice.provider.1=dns,sun
Tried using IP number 10.10.10.7 in place of lorenzo.hjemme.lan
Tried using -Dsonar.login in place of -Dsonar.token
Tried suffixing the sonar.host.url URL with a slash
downgrade sonar-maven-plugin from 5.6.0.6792 to 5.5.0.6356 (the previous version)
And: this used to work, started failing in the week that was.
The only thing that was changed in the build process recently, was upgrading sonar–maven-plugin.
But downgrading sonar–maven-plugin didn’t help either. So I’m thinking it is something outside of my setup…?
But, if it’s outside of my setup, why didn’t I find any hits when searching for the stack trace when googling? That’s kind of strange and points towards something in my setup?
Does anyone know where to find the active issue tracker for sonar-maven-plugin?
I found a Jira, but I couldn’t find any open issues in that Jira. Newest issue was from August 2025 and was closed.
I see others have similar problems in the forum, but not recently and suggestions in replies don’t help me:
Certificate issues: the local build in my home LAN is http, so no certificate. And the failing github build is against sonarcloud, which I presume has its certificate in order
DNS issues: using the IP of the sonar host in the sonar URL didn’t work either (see list of stuff I tried)
I think the message Temporary failure in name resolution is misleading, and that the real reason is something else.
If you look at the list of things I tried you will see an attempt at forcing Java to use DNS and an attempt at using the IP address instead, and they both gave the same error.
Well… the bottom reason is different but other than that it all looks the same stack trace from sonar build · GitHub
Also no other applications have no problem with DNS, and this used to work week before last.
And: I got a very similar-looking stack trace (except for the bottom reason) in github actions starting at about the same time.
The only thing in my build setup that has changed recently was an upgrade to sonar-maven-plugin. But downgrading to the previous version didn’t fix the problem.
There seems to be some kind of connectivity problem…?
It is like the connection comes from a different network segment?
Is scanner-maven-plugin running something in a docker image? Or something…?
Now I have tried one more thing that didn’t work: clearing the elastic index by deleting data/es8
And then I have found something: grepping logs/access*.log for “protobuf” shows that the last time a GET to the protobuf reached the server was on May 4.
And sonar is currently only listening for IPv6 connections:
sb@lorenzo:~$ netstat -tulpn | grep 9900
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp6 0 0 :::9900 :::* LISTEN 40086/java
I haven’t on my own changed anything in the sonar config to make that happen.
The server was rebooted on May 1 (which was before the problem started happening) and then (unnecessarily) on May 8 (which was way after the problem started happening) and then rebooted on May 9 when the new kernel actually arrived.
To fix the IPv6 only issue I have tried to edit the conf/sonar.properties file, setting:
sonar.web.host=0.0.0.0
But that didn’t help either: sonar continues to listen to IPv6 only after a restart.
But at least this explains why nothing seems to reach sonar: it doesn’t.
Both the client and the server are amd64 machines running the latest debian stable, i.e. 13.4 “trixie”. Both were running kernel 6.12.85-1 at the time it started failing (got that kernel on May 1, while builds were successfully updating the server on May 4) and both are currently (since May 8 and 9) running kernel 6.12.86-1.
Would it help to look at the sonar server logs? If so I could pack them up and make them available for download.
Ann, as for the question you asked: So rather than being a SonarScanner for Maven problem, you’re saying this is about what SonarQube is listening to/for?
I don’t really what I’m saying because now I’m poking left and right trying to figure something out.
But, two data points:
The logs of the server shows that May 4 was the last time the URL in question was reached
At about the same time I started getting a similar stack trace (but with a different original error) in github actions builds with sonarcloud
I haven’t knowingly changed anything in sonar config, maven config (except for the sonar-maven-plugin update) or network config in that period of time.
The seemingly listening for IPv6 only, may be a red herring and an artifact of how netstat shows something listening on both IPv4 and IPv6.
These three things together tell me it’s something going on with your network. You’ve got the same problem connecting to both SonarQube self-hosted and SonarQube Cloud → The common denominator there is SonarScanner for Maven. But you eliminated that from the list of possibilities when you ran a successful Maven analysis from the SonarQube host.
In doing so, you removed your network from the test. So what we’re left with is
Well, the sonarcloud thing isn’t from my home network. It is from wherever github actions runs and to sonarcloud.
Other than that I agree with the reasoning.
But I’m running out of ideas for things to try (which is why I started this thread).
The error came out of nowhere but refuses to go away (e.g. when downgrading sonar-maven-plugin).
No other applications have network problems. Not even other java applications. The sonar community runs the java found in the path, which is the same java maven and karaf and eclipse uses.
I removed the offending rule from OpenSnitch on the machine I was running maven on, and then this command built without a hitch, using the newest (5.6.0.6792) sonar-maven-plugin:
