ERROR: Failed to download will retry from controller Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from <Slave id>

Using Jenkins
1

Hi Team,

I have Jenkins controller & agent running on ECS clusters. I’m facing issue for tools download using Jenkins inbound JDK11 image. While downloading the packages which are configured in Jenkins global tools configuration section. It’s downloading the packages however it’s giving below error.

It’s working in JNLP image but it’s deprecated. So preparing the new image using inbound JDK11 image. I have two separate cluster for controller & Salve.

Please help someone?
Unpacking https://repo1.maven.org/maven2/org/sonarsource/scanner/cli/sonar-scanner-cli/4.7.0.2747/sonar-scanner-cli-4.7.0.2747.zip to /home/jenkins/tools/hudson.plugins.sonar.SonarRunnerInstallation/SonarQubeScanner on ECS_agent_CLOUD_1-Jenkins-JNLP-Debian-5rg34
ERROR: Failed to download https://repo1.maven.org/maven2/org/sonarsource/scanner/cli/sonar-scanner-cli/4.7.0.2747/sonar-scanner-cli-4.7.0.2747.zip from agent; will retry from controller
Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from :42722
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1784)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
at hudson.remoting.Channel.call(Channel.java:1000)
at hudson.FilePath.act(FilePath.java:1192)
at hudson.FilePath.act(FilePath.java:1181)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:1044)
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:980)
at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:70)
at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:221)
at hudson.plugins.sonar.SonarRunnerInstallation.forNode(SonarRunnerInstallation.java:99)
at hudson.plugins.sonar.SonarRunnerInstallation.forNode(SonarRunnerInstallation.java:49)
at org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:157)
at org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:138)
at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
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:829)
java.net.UnknownHostException: repo1.maven.org
at java.base/java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.base/java.net.SocksSocketImpl.connect(Unknown Source)
at java.base/java.net.Socket.connect(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.connect(Unknown Source)
at java.base/sun.security.ssl.BaseSSLSocketImpl.connect(Unknown Source)
at java.base/sun.net.NetworkClient.doConnect(Unknown Source)
at java.base/sun.net.www.http.HttpClient.openServer(Unknown Source)
at java.base/sun.net.www.http.HttpClient.openServer(Unknown Source)
at java.base/sun.net.www.protocol.https.HttpsClient.(Unknown Source)
at java.base/sun.net.www.protocol.https.HttpsClient.New(Unknown Source)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(Unknown Source)
at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source)
at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
at java.base/java.net.URL.openStream(Unknown Source)
at upgrade-remoting-to-3244.vf7f977e04755-or-higher 0x9240058//hudson.FilePath$Unpack.invoke(FilePath.java:1080)
at upgrade-remoting-to-3244.vf7f977e04755-or-higher 0x9240058//hudson.FilePath$Unpack.invoke(FilePath.java:1072)
at upgrade-remoting-to-3244.vf7f977e04755-or-higher 0x9240058//hudson.FilePath$FileCallableWrapper.call(FilePath.java:3578)
at hudson.remoting.UserRequest.perform(UserRequest.java:225)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:391)
at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:81)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:140)
at java.base/java.lang.Thread.run(Unknown Source)

Regards,
Venkateswar

2

Please don’t download tools from Maven central for your Jenkins agents. That slows your agent startup while it downloads from Maven central and creates repeated, unnecessary load on Maven central. That type of repeated, unnecessary load on Maven central has caused Sonatype, the donor of Maven central, to consider rate limiting and possibly more drastic measures. More details of the problem are described in the “Tragedy of the commons” blog post.

The Jenkins tool installer plugins (like Eclipse Temurin installer and Oracle Java SE Development Kit installer) offer these usage guidelines:

We want to warn that this plugin is NOT a good practice for production environments. As it relies on Adoptium’s website to do the job, it’s highly likely to stop working. It could happen because Adoptium’s website changes or even if Adoptium bans our downloads due to excessive bandwidth usage or some other reason. Currently Adoptium is using GitHub for hosting release archives and GitHub could also stop working due to similar reasons.

The recommended and preferred approach is to download the JDK distribution using other installers, for example downloading it from a well known URL (preferably hosted on your own network) with ZIP Tool Installer, having it pre-installed in agent docker images, or executing a script to do the job.

Create a location that you host near your Jenkins controller (or inside the /userContent folder of your Jenkins controller) and define the tools to download from that location.

Having the download source closer to your agents may already solve the issue. If it does not solve the issue, it removes a remote host from your further investigation of the issue.

3

Hi MarkEWaite,

Thank you so much for the reply.
We can’t move immediately to new approach due to process. Is their any work around for time being to fix this issue.
We will plan for the right solution.

Can you please help me , if you have any work around for this issue?

Regards,
Venkateswar

4

Sorry, but I don’t have any workaround to offer.

I think you need to reconsider your statement that you can’t move to the recommended approach. I think that your company or organization is misusing a donated resource. You should take immediate steps to stop that misuse. You could stop the misuse by installing some form of local caching server that caches requests to Maven Central. You could stop the misuse
by changing the Jenkins tool definition to download from a nearby server instead of using Maven Central.

When one of the servers of the Jenkins project was being misused by commercial organizations, we were very grateful for those companies that responded to our request to stop the misuse. We were deeply frustrated by those organizations that ignored our requests that they stop misusing the donated services of the Jenkins project.

5

Hi MarkEWaite,

Thanks you for the update.
I will follow your statement.
Thank you for the help and guidance.