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

          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 ?

          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 added a comment -

          Should have gotten to the point of printing something like

          java -version returned 1.7.0_45.

          so since this did not happen, WindowsRemoteProcessLauncher hung. Anything in the Jenkins log?

          Jesse Glick added a comment - Should have gotten to the point of printing something like java -version returned 1.7.0_45. so since this did not happen, WindowsRemoteProcessLauncher hung. Anything in the Jenkins log?

          David Frank added a comment - - edited

          hi,
          looking at the code (for the first time - so forgive me if I'm wrong..) I think method

          private EnvVars getEnvVars(Hudson h) { return getEnvVars(h.getGlobalNodeProperties()); }

          is no longer there (compared with https://github.com/jenkinsci/jenkins/blob/934e9d336b7fb1fb41506fdd525ac98acbf91240/core/src/main/java/hudson/os/windows/ManagedWindowsServiceLauncher.java) with leads to code in

          private EnvVars getEnvVars(SlaveComputer computer)

          fetching only node-local environment variables by calling

          private EnvVars getEnvVars(Node n) { return getEnvVars(n.getNodeProperties()); }

          twice instead of merging local and global ones.

          David Frank added a comment - - edited hi, looking at the code (for the first time - so forgive me if I'm wrong..) I think method private EnvVars getEnvVars(Hudson h) { return getEnvVars(h.getGlobalNodeProperties()); } is no longer there (compared with https://github.com/jenkinsci/jenkins/blob/934e9d336b7fb1fb41506fdd525ac98acbf91240/core/src/main/java/hudson/os/windows/ManagedWindowsServiceLauncher.java ) with leads to code in private EnvVars getEnvVars(SlaveComputer computer) fetching only node-local environment variables by calling private EnvVars getEnvVars(Node n) { return getEnvVars(n.getNodeProperties()); } twice instead of merging local and global ones.

          Jesse Glick added a comment -

          @dave8304 getEnvVars(Hudson) was deleted earlier in https://github.com/jenkinsci/jenkins/commit/24052ea59026a0690c07ee14579a681114ad93e5 since it was unused. That is not a change from the code immediately prior to the split.

          Jesse Glick added a comment - @dave8304 getEnvVars(Hudson) was deleted earlier in https://github.com/jenkinsci/jenkins/commit/24052ea59026a0690c07ee14579a681114ad93e5 since it was unused. That is not a change from the code immediately prior to the split.

          Jesse Glick added a comment -

          Jesse Glick added a comment - Possibly: https://github.com/jenkinsci/jenkins/pull/1106

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/f9810b5131e3024930df233a02a356e3cb5b5f84
          Log:
          JENKINS-21373 Noting.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html http://jenkins-ci.org/commit/jenkins/f9810b5131e3024930df233a02a356e3cb5b5f84 Log: JENKINS-21373 Noting.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3192
          JENKINS-21373 Noting. (Revision f9810b5131e3024930df233a02a356e3cb5b5f84)

          Result = SUCCESS
          Jesse Glick : f9810b5131e3024930df233a02a356e3cb5b5f84
          Files :

          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #3192 JENKINS-21373 Noting. (Revision f9810b5131e3024930df233a02a356e3cb5b5f84) Result = SUCCESS Jesse Glick : f9810b5131e3024930df233a02a356e3cb5b5f84 Files : changelog.html

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

              Created:
              Updated:
              Resolved: