Repository navigation
[JENKINS-48754] Jenkins Slaves do not connect after update from version 2.95 to version 2.99 #1294
Description
After having installed Jenkins Version 2.99, none of my slaves did connect to the server anymore. Even a restart of the java script on the slave did not help.
Workaround: Update Remoting on the agent side to 3.15
Originally reported by 
michaelmotteler, imported from: Jenkins Slaves do not connect after update from version 2.95 to version 2.99
- assignee:
oleg_nenashev
- status: Resolved
- priority: Blocker
- component(s): remoting
- resolution: Duplicate
- resolved: 2018-01-18T08:35:49+00:00
- votes: 4
- watchers: 11
- imported: 2025-11-25
Raw content of original issue
After having installed Jenkins Version 2.99, none of my slaves did connect to the server anymore. Even a restart of the java script on the slave did not help.
Workaround: Update Remoting on the agent side to 3.15
environment
Windows 7, Jenkins 2.95 -> 2.99<br/>
I have about 5-7 Slaves connecting to the Jenkins server (using JNLP 1 - since I am in a safe business intranet area)<br/>
CentOS root, macOS Agents connecting to the root node with JNLP4. <br/>
Workaround: Update Remoting on the agent side to 3.15
Activity
jenkins-infra-bot commentedon Jan 2, 2018
Remote link associated with this issue:
jenkins-infra-bot commentedon Jan 2, 2018
blaoueille:
Raw content of original comment:
Hi,
I've exactly the same problem.
Agent log :
janv. 02, 2018 3:05:49 PM hudson.remoting.jnlp.Main createEngine
INFO: Setting up slave: Windows Slave
janv. 02, 2018 3:05:49 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using D:\Jenkins\remoting as a remoting work directory
Both error and output logs will be printed to D:\Jenkins\remoting
janv. 02, 2018 3:05:49 PM org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver resolve
INFO: Remoting server accepts the following protocols: [JNLP4-connect, Ping]
janv. 02, 2018 3:06:00 PM hudson.remoting.jnlp.GuiListener$1 run
INFO: Connecting to ciserver:8081 (retrying:2)
java.io.IOException: Failed to connect to ciserver:8081
{{ at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:242)}}
{{ at hudson.remoting.Engine.connect(Engine.java:686)}}
{{ at hudson.remoting.Engine.innerRun(Engine.java:547)}}
{{ at hudson.remoting.Engine.run(Engine.java:469)}}
Caused by: java.net.ConnectException: Connection refused: connect
{{ at sun.nio.ch.Net.connect0(Native Method)}}
{{ at sun.nio.ch.Net.connect(Unknown Source)}}
{{ at sun.nio.ch.Net.connect(Unknown Source)}}
{{ at sun.nio.ch.SocketChannelImpl.connect(Unknown Source)}}
{{ at java.nio.channels.SocketChannel.open(Unknown Source)}}
{{ at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:203)}}
{{ ... 3 more}}
And in master log nothing appears...
Regards,
Bruno.
jenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
Which agent version do you use?
jenkins-infra-bot commentedon Jan 2, 2018
blaoueille:
Raw content of original comment:
For me : I've uninstalled my Windows Service agent and click again on "Launch agent from browser". I guess it's the latest with this method ?
In the agent.jar manifest file it's written 3.15 for the version...
jenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
My first guess is that Remoting receiver thread is not active due to whatever reason. Or maybe not, the HTTPs receiver should be working
Please provide...
1) Jenkins log, starting from the master startup
2) Thread dump for the master
If you could just generate a bundle using https://wiki.jenkins.io/display/JENKINS/Support+Core+Plugin, it would be great
jenkins-infra-bot commentedon Jan 2, 2018
blaoueille:
Raw content of original comment:
Hi,
I hope it's what you asked :
support_2018-01-02_17.45.19.zip
master-logs.txt
jenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
Some investigation while I am waiting for the info...
1) No changes in JnlpAgentEndpoint since 2.95
2) No changes in Engine#connect()
3) AFAICT #210 is the most plausible source of regressions, but I do not see the bogus logic so far.
Please also provide agent startup arguments
jenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
A full support bundle would help though. In particular I am interested whether the agent uses HTTPS and what are the certificate check flags
jenkins-infra-bot commentedon Jan 2, 2018
blaoueille:
Raw content of original comment:
Yes here : support_2018-01-02_18.01.52.zip
jenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
"TCP agent listener port=8081" id=53 (0x35) state=RUNNABLE cpu=0% (running 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) at hudson.TcpSlaveAgentListener.run(TcpSlaveAgentListener.java:157)Yes, for JNLP agent I really need startup arguments.
Other info:
jenkins-infra-bot commentedon Jan 2, 2018
blaoueille:
Raw content of original comment:
OK, How can I retrieve agent startup arguments ?
On startup page for the agent start through the browser I have
java -jar agent.jar -jnlpUrl http://myserver:10004/computer/Windows%20Slave/slave-agent.jnlp -secret **************************************************************** -workDir "D:\Jenkins"
(Note: I've replaced the real server name by myserver, and changed the secret code).
jenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
Yes, it's what I needed. Now it's a time to reproduce it
jenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
Seeing something very similar.
In a job:
Starting the agent up:
Agent is launched like so:
java -jar agent.jar -jnlpUrl https:///computer//slave-agent.jnlp -secretjenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
panajev could you please create a separate ticket for now? I am not 100% sure the issues are same, but in the case of your stacktraces I know what to fix
jenkins-infra-bot commentedon Jan 2, 2018
Raw content of original comment:
Regarding the issue from panajev, updating agent to Remoting 3.15 is a workaround, working on a fix
9 remaining items
jenkins-infra-bot commentedon Jan 4, 2018
Raw content of original comment:
Please check which port is exposed up for TcpAgentListener, and make sure the same port is configured in the security global config. Since you run in Docker, I would definitely recommend setting port flags so that the port won't be changeable from UI:
-Djenkins.model.Jenkins.slaveAgentPort=${YOUR_EXPOSED_PORT} -Djenkins.model.Jenkins.slaveAgentPortEnforce=trueExample for Docker
"TCP agent listener port=0" id=86 (0x56) state=RUNNABLE cpu=0% (running 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) at hudson.TcpSlaveAgentListener.run(TcpSlaveAgentListener.java:157)OK, Docker... So far I can say the following:
Please check which port is exposed up for TcpAgentListener, and make sure the same port is configured in the security global config. Since you run in Docker, I would definitely recommend setting port flags so that the port won't be changeable from UI:
Example for Docker
jenkins-infra-bot commentedon Jan 5, 2018
blaoueille:
Raw content of original comment:
Yes it's ok for that, moreover the configuration has not changed on that. We have put the 8081 port for Tcp agents with only JNLP/4 and it is accessible and configured on our Docker. (It was working well before updates).
jenkins-infra-bot commentedon Jan 18, 2018
Raw content of original comment:
Back to this story...
> We have put the 8081 port
How did you do that? The threaddump definitely suggests you're running with a random port
jenkins-infra-bot commentedon Jan 18, 2018
blaoueille:
Raw content of original comment:
Hi,
Sorry for late answer. But you are right, the configuration of the connection through tuneling was not set for the slave. I forgot it after my second installation (it was set only in the global security part).
So after correcting this part the new version has worked perfectly.
Thank you for your support.
Regards,
Bruno.
jenkins-infra-bot commentedon Jan 18, 2018
Raw content of original comment:
Thanks for the reply! So this is not a defect. I will close it as a duplicate of
JENKINS-48761, because the most of the voters/watchers followed the summary of the issue && timing was very coincidentaljenkins-infra-bot commentedon Nov 25, 2025
[Original
relates_tofrom Jira: JENKINS-48766]jenkins-infra-bot commentedon Nov 25, 2025
[Original
relates_tofrom Jira: JENKINS-48761]