Your JNLP agent cannot be connected with your Jenkins master.
- CloudBees CI (CloudBees Core) - Modern cloud platforms
- CloudBees CI (CloudBees Core) - Traditional platforms - Client Master
- CloudBees CI (CloudBees Core) - Traditional platforms - Operations Center
- CloudBees Jenkins Platform Client Master
- CloudBees Jenkins Platform Operations Center
- CloudBees Jenkins Enterprise
Since CloudBees Core 22.214.171.124 it is possible to connect your agents through Websockets instead of JNLP, which simplifies the connectivity at the infrastrucuture level getting the same result with less complexity. This is not really a workaround, but a different approach which can be used insead of JNLP. This is the recommended approach specially in Kubernetes environments where CloudBees do not recommend to use JNLP for external connectivity.
Despite all of this, if you still need to use JNLP, in order to successfully connect a JNLP agent with your Jenkins environment there are a few important pre-requisites:
- The CloudBees Core instance must be listening on the JNLP port
- The CloudBees Core instance must be reachabe at HTTP level from the JNLP agent
- The CloudBees Core instance must be reachable at TCP level from the JNLP agent
Starting in Jenkins core 2.217 the Websocket feature landed in Jenkins. This improvement provides WebSocket support to Jenkins, available when connecting inbound agents or when running the CLI. The WebSocket protocol allows bidirectional, streaming communication over an HTTP(S) port.
Since CloudBees Core 126.96.36.199 you can use WebSocket transport to connect inbound agents, and this works as well for shared agents / clouds. Just select the WebSocket checkbox in agent / cloud configuration and ensure that the agent is launched with the
-webSocket option. No special network configuration is needed, since the regular HTTP(S) port proxied by the CloudBees Core ingress is used for all communications.
The main benefit of Websockets over JNLP is that it simplifies the connectivity as you will not need to configure JNLP port in the networking elements in front of Jenkins for the connectivity to happen. Websocket is compatible with HTTP protocol so it uses the Jenkins URL for the communication.
Go to Manage Jenkins -> Configure Global Security and ensure that the JNLP port was configured with a either fixed, or random port and that the Agent protocol
Inbound TCP Agent Protocol/4 (TLS encryption) is at least enabled.
Take a thread dump of the instance going to
<JENKINS_URL>/threadDump from your web browser and look for the
TCP agent listener thread.
TCP agent listener port=31966 "TCP agent listener port=31966" Id=89 Group=main RUNNABLE (in native) at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) - locked java.lang.Object@7b1b2a2 at hudson.TcpSlaveAgentListener.run(TcpSlaveAgentListener.java:186)
From the agent side run the command
curl -ILv <JENKINS_URL> and check if you are getting the Jenkins headers such as:
... < X-Hudson: 1.395 X-Hudson: 1.395 < X-Hudson-CLI-Port: 31966 X-Hudson-CLI-Port: 31966 < X-Jenkins: 188.8.131.52 X-Jenkins: 184.108.40.206 < X-Jenkins-CLI-Host: ec2-74-159-31-69.compute-1.amazonaws.com X-Jenkins-CLI-Host: ec2-74-159-31-69.compute-1.amazonaws.com ...
You can test if the CliudBees Core instance is reachable through TCP protocol by either
telnet <JENKINS_HOSTNAME> <JNLP_PORT> or
A good practice is to run the exactly same Java version in both Jenkins and agent, but when this is not possible it is recommendable to be running at least the same base line.
java -version in both Jenkins master box and agent to check the java version you are running in both.
The main problem of running JNLP as an agent Launcher is that when you upgrade Jenkins
agent.jar is not automatically upgraded on the agent - which by the way happens in SSH Launcher out of the box.
agent.jar is the same using for example
agent.jar can be downloaded from Jenkins master from the URL below:
In the agent box download <JENKINS_URL>/jnlpJars/jenkins-cli.jar from Jenkins master and execute the command below:
java -jar jenkins-cli.jar -s http://<CJOC_URL>/ --username=<USERNAME> --password=<PASSWORD> help
Launch the commands below and check that the port and hostname are the right ones:
curl -I <JENKINS_URL>/computer/<AGENT>/slave-agent.jnlp curl -I <JENKINS_URL>/tcpSlaveAgentListener/
Curl command can be available on a Windows box using for example curl Download Wizard
If you are using a load balancer or a ha-proxy and you are not running Jenkins on ha mode, you might want to bypass any of them through the Agent advance option of
Tunnel connection through.
If, when starting the JNLP file, you see an error like the one below, run the command
javaws -clearcache to clear the cache of the java webstart program.
java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at sun.security.ssl.InputRecord.readFully(Unknown Source) at sun.security.ssl.InputRecord.read(Unknown Source) at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.access$200(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivilegedWithCombiner(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source) at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source) at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source) at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
- Architecture diagram so we can understand how it looks like your environment
- A support bundle
agent.jarin both boxes
- Content of <JENKINS_URL>/computer/
- Content of <JENKINS_URL>/computer/
- Output of commands below launched from agent box
- The agent and the master logs which demonstrates that the connectivity is broken
curl -I <JENKINS_URL>/computer/<AGENT>/slave-agent.jnlp curl -I <JENKINS_URL>/tcpSlaveAgentListener/ curl -ILv <JENKINS_URL>