Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-21373

Unable to connect to Windows slave after upgrade to Jenkins ver. 1.547

      After upgrading Jenkins to version 1.547 it's not possible to connect to a Windows slave annymore.

      The only log output is:
      Connecting to <servername>
      Checking if Java exists

      Java is installed and works.

          [JENKINS-21373] Unable to connect to Windows slave after upgrade to Jenkins ver. 1.547

          Jürgen Prechtl created issue -

          Tom Jones added a comment - - edited

          I'm seeing the same problem. Everything was working before the upgrade (ver. 1.544) but immediately after the upgrade all of my windows slaves are failing with the same problem. The windows slave has the following log message:

          Exception in thread "main" java.net.SocketTimeoutException: Accept timed out
          at java.net.DualStackPlainSocketImpl.waitForNewConnection(Native Method)
          at java.net.DualStackPlainSocketImpl.socketAccept(Unknown Source)
          at java.net.AbstractPlainSocketImpl.accept(Unknown Source)
          at java.net.PlainSocketImpl.accept(Unknown Source)
          at java.net.ServerSocket.implAccept(Unknown Source)
          at java.net.ServerSocket.accept(Unknown Source)
          at hudson.remoting.Launcher.runAsTcpServer(Launcher.java:385)
          at hudson.remoting.Launcher.run(Launcher.java:236)
          at hudson.remoting.Launcher.main(Launcher.java:192)

          Tom Jones added a comment - - edited I'm seeing the same problem. Everything was working before the upgrade (ver. 1.544) but immediately after the upgrade all of my windows slaves are failing with the same problem. The windows slave has the following log message: Exception in thread "main" java.net.SocketTimeoutException: Accept timed out at java.net.DualStackPlainSocketImpl.waitForNewConnection(Native Method) at java.net.DualStackPlainSocketImpl.socketAccept(Unknown Source) at java.net.AbstractPlainSocketImpl.accept(Unknown Source) at java.net.PlainSocketImpl.accept(Unknown Source) at java.net.ServerSocket.implAccept(Unknown Source) at java.net.ServerSocket.accept(Unknown Source) at hudson.remoting.Launcher.runAsTcpServer(Launcher.java:385) at hudson.remoting.Launcher.run(Launcher.java:236) at hudson.remoting.Launcher.main(Launcher.java:192)

          Steve Poulsen added a comment -

          I am seeing the same issue with the log ending at "Checking if Java exists". The hour glass spins, but if you click the node, it shows it is no longer trying.

          I can switch the node to Java WebStart and that works, but only if I disable it as a VirtualBox slave. If it is a VirtualBox slave, it goes into a JNLP starting loop, repeatedly.

          Steve Poulsen added a comment - I am seeing the same issue with the log ending at "Checking if Java exists". The hour glass spins, but if you click the node, it shows it is no longer trying. I can switch the node to Java WebStart and that works, but only if I disable it as a VirtualBox slave. If it is a VirtualBox slave, it goes into a JNLP starting loop, repeatedly.

          Exact same issue here. Downgrading to 1.546 fixes it.

          Deniz Zoeteman added a comment - Exact same issue here. Downgrading to 1.546 fixes it.

          Chris Eagan added a comment - - edited

          We have started seeing this error as well and it is affecting all of our Windows Slaves. Does anyone know how to get more debugging information regarding this issue?

          I downgraded to version 1.546 and things are working fine again, so the issue was definitely introduced at that point.

          Chris Eagan added a comment - - edited We have started seeing this error as well and it is affecting all of our Windows Slaves. Does anyone know how to get more debugging information regarding this issue? I downgraded to version 1.546 and things are working fine again, so the issue was definitely introduced at that point.

          According to the changelog for 1.547, the windows-slaves-plugin was split off from core. The bug was probably introduced in commit 2669e4a86d

          Perhaps some classes are now missing on the windows slave when it tries to start it ?

          Willem Verstraeten added a comment - According to the changelog for 1.547, the windows-slaves-plugin was split off from core. The bug was probably introduced in commit 2669e4a86d Perhaps some classes are now missing on the windows slave when it tries to start it ?
          Willem Verstraeten made changes -
          Component/s New: windows-slaves [ 18327 ]

          Jesse Glick added a comment -

          The split did not change the code, and should not have changed library versions either, but perhaps it introduced some kind of class loading issue. Will need @kohsuke’s assistance to get a suitable test environment.

          Jesse Glick added a comment - The split did not change the code, and should not have changed library versions either, but perhaps it introduced some kind of class loading issue. Will need @kohsuke’s assistance to get a suitable test environment.
          Jesse Glick made changes -
          Component/s Original: core [ 15593 ]
          Component/s Original: plugin [ 15491 ]
          Labels New: regression
          Priority Original: Major [ 3 ] New: Blocker [ 1 ]
          Jesse Glick made changes -
          Assignee New: Kohsuke Kawaguchi [ kohsuke ]

            kohsuke Kohsuke Kawaguchi
            juprecht Jürgen Prechtl
            Votes:
            16 Vote for this issue
            Watchers:
            28 Start watching this issue

              Created:
              Updated:
              Resolved: