I’ve been searching and trying things but so far without success. The instructional videos assume you’re running Linux so they’re not much use. I thought I’d try here.
I have a server running LTS Jenkins on the built-in Java. I have workers using the latest JRE from Oracle. That works perfectly well. Reading the warning about Java 8 going out of support I thought I’d try changing to Java 11.
It seemed like a straightforward idea - I downloaded the Microsoft build of OpenJDK 11 from here Download the Microsoft Build of OpenJDK | Microsoft Docs then extracted it on the Jenkins server and one of the workers. I go to jenkins.xml and change this %BASE%\jre\bin\java to point at the MS version, that seems to go OK. I then get the worker to run the MS Java, “java -version” tells me it’s OK and the service starts normally.
So far so good, except the controller can’t connect to the worker. Is there something else? Presumably I’ve missed something important, I thought just moving both machines to use the same Java 11 would get it working.
Whats jenkins.xml? Is that on one of the agents? When you say it can’t connect, what does it say? How are you connecting to your agents? Ssh? jnlp? …um… other thing?
I’m thinking maybe because agent.jar got updated and you didn’t download the latest release for your agent, but without more info its a pretty big shot in the dark
jenkins.xml is a file on the management server in C:\Jenkins, the same folder as jenkins.exe.
It said unable to connect, like it does when the service isn’t running on the worker.
The workers have their own XML file which has a line which refers to slave-agent.jar: java.exe -Xrs -Djsse.enableSNIExtension=false -jar “%BASE%\remoting-4.13.2.jar” -jnlpUrl http://jenkins/computer/Android%20Java%20(2)/slave-agent.jnlp -secret (long_secret_number)
I’m running the latest LTS (2.346.2) and the workers are running the version of remoting.jar which came with it. Everything works perfectly until I change the java version.
The command line in your agent configuration indicates that you’re using an inbound agent to connect to the Jenkins controller. That’s a common configuration, especially on Windows agents. In that case, the agent initiates the connection to the controller. The controller does not initiate the connection to the agent.
If you can open the agent configuration page on the Jenkins controller, it will provide the command line that you can use to start the agent. Confirm that command line matches the command that you’re using in your agent configuration. As a temporary experiment, try running that command line from a command prompt window. That may provide some additional messages that will help you diagnose the issue.
java.net.ConnectException: Connection timed out: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:508)
at hudson.remoting.Launcher.run(Launcher.java:346)
at hudson.remoting.Launcher.main(Launcher.java:297)
Waiting 10 seconds before retry
Failed to obtain http://jenkins.chyp.com/computer/Javacard%20%283%29/jenkins-agent.jnlp?encrypt=true
java.net.ConnectException: Connection timed out: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:508)
at hudson.remoting.Launcher.run(Launcher.java:346)
at hudson.remoting.Launcher.main(Launcher.java:297)
Waiting 10 seconds before retry
As I say, if I set the manager and workers to use Java 1.8 everything works. I don’t change anything else. The secret numbers and command lines are exactly the same.
There is a hyperlink to agent.jar in the command line provided on that page. Use that hyperlink to download agent.jar. Then run the command to see if it provides more diagnostic information.
If I try to explain what I did I keep getting told that I can’t post a link to a post, whatever that means. Using the other jar file doesn’t change anything.
I can change the Java back to 8 on the manager and worker without making any other changes to the configuration and everything works again. It makes me think it’s Java 11 which is causing it to fail for some reason but the error doesn’t really help.
You definitily have an outdated setup on the old agents. The jlnp endpoint changed to jenkins-agent (instead of slave-agent, so this still can be ues). I would really open the agent page on the controller, move the old agent dir contents on the agent away and execute the shown commands (all lof them!) afresh.
LOL - having to explain it carefully to other people will eventually help you. Check your firewall settings and make sure you didn’t specifically allow the version of Java in the Jenkins folder like I did.
It works briefly now but with the manager and worker on version 11 I get
Aug 05, 2022 10:00:06 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connected
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter to field java.lang.reflect.Field.modifiers
WARNING: Please consider reporting this to the maintainers of org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
After that it disconnects. The manager says
java.nio.channels.ClosedChannelException
at org.jenkinsci.remoting.protocol.NetworkLayer.onRecvClosed(NetworkLayer.java:155)
at org.jenkinsci.remoting.protocol.impl.NIONetworkLayer.ready(NIONetworkLayer.java:180)
at org.jenkinsci.remoting.protocol.IOHub$OnReady.run(IOHub.java:789)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
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)
If I switch the worker back to Java 8 it works, even with the manager on version 11. Nearly there…
I’ll keep the narration going in case someone else ends up here looking for answers. As I’ve got past the issue with the firewall and got everything running in Java 11 I thought I’d have a go at switching the service to use it. I’ve done this in jenkins.xml on the workers:
