-
Bug
-
Resolution: Fixed
-
Critical
-
Powered by SuggestiMate
jnlp windows slave won't start using the gui launch button.
- screenshot-2.png
- 15 kB
- marlene cote
- screenshot-1.png
- 15 kB
- marlene cote
[JENKINS-39596] JNLPSlave fails to connect with Java WebStart call
Please provide....
1) You current Jenkins version
2) List of enabled remoting protocols
3) Agent configuration
I see the failure with the following error in the Jenkins startup log. Not sure if it's the same issue (running on Mac), but the behavior is the same
<===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 3.0 This is a Unix agent java.net.MalformedURLException: no protocol: jnlpJars/slave.jar at java.net.URL.<init>(URL.java:593) at java.net.URL.<init>(URL.java:490) at org.jenkinsci.modules.slave_installer.impl.InstallerGui.call(InstallerGui.java:65) at org.jenkinsci.modules.slave_installer.impl.InstallerGui.call(InstallerGui.java:34) at hudson.remoting.UserRequest.perform(UserRequest.java:153) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:332) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:94) at java.lang.Thread.run(Thread.java:745) at ......remote call to Channel to /127.0.0.1(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1435) at hudson.remoting.UserResponse.retrieve(UserRequest.java:253) at hudson.remoting.Channel.call(Channel.java:795) at org.jenkinsci.modules.slave_installer.impl.ComputerListenerImpl.onOnline(ComputerListenerImpl.java:32) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:581) at jenkins.slaves.DefaultJnlpSlaveReceiver.afterChannel(DefaultJnlpSlaveReceiver.java:171) at org.jenkinsci.remoting.engine.JnlpConnectionState$4.invoke(JnlpConnectionState.java:421) at org.jenkinsci.remoting.engine.JnlpConnectionState.fire(JnlpConnectionState.java:312) at org.jenkinsci.remoting.engine.JnlpConnectionState.fireAfterChannel(JnlpConnectionState.java:418) at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$1.call(LegacyJnlpProtocolHandler.java:113) at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$1.call(LegacyJnlpProtocolHandler.java:104) at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
System log:
Nov 09, 2016 12:51:57 PM hudson.TcpSlaveAgentListener$ConnectionHandler run INFO: Accepted connection #28 from /127.0.0.1:61584 Nov 09, 2016 12:52:02 PM hudson.node_monitors.ResponseTimeMonitor$1 monitor WARNING: Making DumbJNLPAgent offline because it’s not responding
Confirmed the bug. remoting Engine class does not set up hudsonUrl starting from remoting 3.0
sorry I didn't provide those, I figured since they were provided in the other bug I opened, it would be enough. Do you still need the info you requested?
other bug I opened
There is no bug linked from here, and we're not psychic. Please always include all relevant information. Copy & paste should be fine.
I do not need any additional info. I've reproduced the issue, fixed it and confirmed the fix works on my environment. Hopefully we will get the fix in 2.31. Regarding the JNLP signature warning, it should be another story
Daniel, I thought I was communicating with Oleg. He asked me to open this one from another one and to assign this one to him. I didn't consider the possibility that there would be confusion around it.
About Jenkins 2.30
All Agent protocols enabled except 3 and 4.
Oleg, what do you mean by "Regarding the JNLP signature warning, it should be another story"?
I need the slaves to work. These problems are preventing us from moving forward with version 2.x rollout.
thank you.
Oleg, what do you mean by "Regarding the JNLP signature warning, it should be another story"?
I need the slaves to work. These problems are preventing us from moving forward with version 2.x rollout.
thank you.
He's referring to the warning about hudson.showWindowsServiceInstallLink which AFAICT has no negative impact on anything.
Code changed in jenkins
User: Oleg Nenashev
Path:
src/main/java/hudson/remoting/Engine.java
src/main/java/org/jenkinsci/remoting/engine/JnlpAgentEndpoint.java
src/main/java/org/jenkinsci/remoting/engine/JnlpAgentEndpointResolver.java
http://jenkins-ci.org/commit/remoting/837bfeb81e8ed360e8350711b59fb8d9f3311882
Log:
JENKINS-39596 - Restore assigning of hudsonUrl in hudson.remoting.Engine
It's a regression in remotirn-3.0
Code changed in jenkins
User: Oleg Nenashev
Path:
src/main/java/hudson/remoting/Engine.java
src/main/java/org/jenkinsci/remoting/engine/JnlpAgentEndpoint.java
src/main/java/org/jenkinsci/remoting/engine/JnlpAgentEndpointResolver.java
http://jenkins-ci.org/commit/remoting/e0cfb18cc844d6f027df64f76c9b3fc0aa4ec2bb
Log:
Merge pull request #131 from oleg-nenashev/bug/JENKINS-39596
[JENKINS-39596,JENKINS-39617] - hudsonUrl in Remoting Engine was always null since 3.0
Compare: https://github.com/jenkinsci/remoting/compare/fa398e1aa531...e0cfb18cc844
Oleg, not sure if it is possible, but I am happy to test your fix if you would like?
We need to get a signed remoting version in order to allow testing by users. Hopefully we will get it today
We are unable to use our Windows slaves as a consequence of this. Is there a workaround or imminent fix please?
Currently I'm waiting for the votes in https://github.com/jenkinsci/jenkins/pull/2628
Workarounds:
- Use a SNAPSHOT build of the Jenkins core with the fix (e.g. https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/6499/artifact/war/target/jenkins.war)
- Do not start slaves from Web UI, use CLI commands instead
Hmm, well actually I am launching my slave using the command:
javaws http://<<ip>>:8080/computer/SYDWIN01/slave-agent.jnlp
and not the web UI. I get the same issue with either.
What alternative can I use to get it working?
Thanks
Oleg, my master is linux. can I use a yum or rpm command to get that version of the war file?
For Matt Adams, I got around this temporarily by creating a bat file on my windows slave that is kicked off by the task scheduler. the bat file uses the java command line instead of the javaws command line.
java -jar c:\jenkins\slave.jar -jnlpUrl http://XX.XX.XX.XX:8080/computer/SLAVENAME/slave-agent.jnlp
> Oleg, my master is linux. can I use a yum or rpm command to get that version of the war file?
No, we do not publish snapshot builds in Package managers.
But you can just replace jenkins.war and then update package to 2.31 once it gets released
the new jenkins.war fixed the problem with the slave! thank you very much.
I get the same issue with either.
Didn't you tell me the CLI launcher is unaffected by this?
Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
http://jenkins-ci.org/commit/jenkins/7a948d399585d201c4132597aed5723a495acf69
Log:
Update remoting to 2.31 in the Jenkins core. (#2628)
The change introduces one serious bugfix (JENKINS-39596) and a bunch of various diagnostics improvements.
Bugfixes:
JENKINS-39596(https://issues.jenkins-ci.org/browse/JENKINS-39596) -
Jenkins URL in `hudson.remoting.Engine` was always `null` since `3.0`.
It was causing connection failures of Jenkins JNLP agents when using Java Web Start.
(PR #131(https://github.com/jenkinsci/remoting/pull/131))JENKINS-39617(https://issues.jenkins-ci.org/browse/JENKINS-39617) -
`hudson.remoting.Engine` was failing to establish connection if one of the URLs parameter in parameters was malformed.
(PR #131(https://github.com/jenkinsci/remoting/pull/131))
Improvements:
JENKINS-39150(https://issues.jenkins-ci.org/browse/JENKINS-39150) -
Add logic for dumping diagnostics across all the channels.
(PR #122(https://github.com/jenkinsci/remoting/pull/122), PR #125(https://github.com/jenkinsci/remoting/pull/125))JENKINS-39543(https://issues.jenkins-ci.org/browse/JENKINS-39543) -
Improve the caller/callee correlation diagnostics in thread dumps.
(PR #119(https://github.com/jenkinsci/remoting/pull/119))JENKINS-39290(https://issues.jenkins-ci.org/browse/JENKINS-39290) -
Add the `org.jenkinsci.remoting.nio.NioChannelHub.disabled` flag for disabling NIO (mostly for debugging purposes).
(PR #123(https://github.com/jenkinsci/remoting/pull/123))JENKINS-38692(https://issues.jenkins-ci.org/browse/JENKINS-38692) -
Add extra logging to help diagnosing `IOHub` Thread spikes.
(PR #116(https://github.com/jenkinsci/remoting/pull/116))- JENKINS-39289(https://issues.jenkins-ci.org/browse/JENKINS-39289) -
When a proxy fails, report what caused the channel to go down.
(PR #128(https://github.com/jenkinsci/remoting/pull/128))