• Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Major Major
    • core
    • None

      I've upgraded to latest Hudson 1.366 from 1.361 and my windows slave stopped working.

      Even though I've configured the slave box to have %JAVA_HOME% set and %JAVA_HOME%/bin, "java" command works just fine on cmd.exe shell

      C:\WINDOWS>java -fullversion
      java full version "1.6.0_21-b06"

      Hudson fails to recognize it and tries to install jdk which also fails.

      Connecting to w2k3fm1
      Checking if Java exists
      'java' is not recognized as an internal or external command, operable program or batch file.
      No Java found. Downloading JDK Installing JDK
      ERROR: Failed to prepare Java jcifs.smb.SmbException: Cannot create a file when that file already exists.
       at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:545)
       at jcifs.smb.SmbTransport.send(SmbTransport.java:646)
       at jcifs.smb.SmbSession.send(SmbSession.java:244)
       at jcifs.smb.SmbTree.send(SmbTree.java:119)
       at jcifs.smb.SmbFile.send(SmbFile.java:770)
       at jcifs.smb.SmbFile.mkdir(SmbFile.java:2518)
       at jcifs.smb.SmbFile.mkdirs(SmbFile.java:2544)
       at hudson.os.windows.WindowsRemoteFileSystem.mkdirs(WindowsRemoteFileSystem.java:58)
       at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:167)
       at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:184)
       at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
       at java.util.concurrent.FutureTask.run(FutureTask.java:138)
       at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
       at java.lang.Thread.run(Thread.java:619)
      Copying slave.jar Starting the service 
      

          [JENKINS-6957] Windows slave fails to find java

          Same issue experienced here with Master on Windows 2003 R2 32bit, JDK 1.6.0_20, Tomcat 6.0.20 and Hudson Slaves on Windows 2008 64bit, with JDK 1.6.0_20, JAVA_HOME set correctly and java binary available on path.

          All nodes (Master and Slaves) have their own JDK section(s) like the following:

          • Name: JDK 1.6.0_20
          • JAVA_HOME: D:\Hudson\Tools\jdk1.6.0_20
          • Install automatically: deselected

          It seems the new feature is too eager to attempt a remote JDK install/deployment without verifying first the actual node setup.

          Switching back to 1.365 resolves the experience issue.

          Andrea Barbieri added a comment - Same issue experienced here with Master on Windows 2003 R2 32bit, JDK 1.6.0_20, Tomcat 6.0.20 and Hudson Slaves on Windows 2008 64bit, with JDK 1.6.0_20, JAVA_HOME set correctly and java binary available on path. All nodes (Master and Slaves) have their own JDK section(s) like the following: Name: JDK 1.6.0_20 JAVA_HOME: D:\Hudson\Tools\jdk1.6.0_20 Install automatically: deselected It seems the new feature is too eager to attempt a remote JDK install/deployment without verifying first the actual node setup. Switching back to 1.365 resolves the experience issue.

          This issue is still present in Hudson 1.372. I really would consider this bug a blocker. Stuck at 1.365 until this situation is resolved.

          Andrea Barbieri added a comment - This issue is still present in Hudson 1.372. I really would consider this bug a blocker . Stuck at 1.365 until this situation is resolved.

          issue still present in 1.375.

          Master on a Win2003 R2 32bit host.
          Slaves instantiated via WMI and running Windows 2008 64bit

          JDK 1.6.0_20 installed on every system (Master and Slaves). JAVA_HOME set everywhere accordingly to the local installation.

          is anyone with the same master-slaves configuration experiencing the reported issue?

          it seems very likely the culprit is in these two "enhancements":

          1. Hudson can now remotely install JDK on Windows slaves when connecting via the "Let Hudson control this Windows slave as a Windows service" mode.
          2. The "Let Hudson control this Windows slave as a Windows service" mode now allows the same Windows slave to be used by multiple Hudson masters.

          Does an existing (pre 1.366) Windows slave require any kind of "fixing" for this enhancement update to work?

          Andrea Barbieri added a comment - issue still present in 1.375. Master on a Win2003 R2 32bit host. Slaves instantiated via WMI and running Windows 2008 64bit JDK 1.6.0_20 installed on every system (Master and Slaves). JAVA_HOME set everywhere accordingly to the local installation. is anyone with the same master-slaves configuration experiencing the reported issue? it seems very likely the culprit is in these two "enhancements": Hudson can now remotely install JDK on Windows slaves when connecting via the "Let Hudson control this Windows slave as a Windows service" mode. The "Let Hudson control this Windows slave as a Windows service" mode now allows the same Windows slave to be used by multiple Hudson masters. Does an existing (pre 1.366) Windows slave require any kind of "fixing" for this enhancement update to work?

          Jimmy Bergman added a comment - - edited

          The cause of this is:
          1. The "Checking if Java exists" uses WindowsRemoteProcessLauncher, which executes code by installing a service running a 32 bit application, that in turn runs the requested commands
          2. Windows 7 and Windows 2008 64 bit runs 32 bit apps in WOW64 compat mode, see http://serverfault.com/questions/208399/windows-7-system32-different-contents-depending-on-how-its-viewed
          3. The newest version of java installs java.exe in c:\windows\system32

          Workaround:
          copy c:\windows\system32\java.exe c:\windows\syswow64

          But the real fix would be to either change algorithm for executing the command, or if continuing to use https://github.com/jenkinsci/lib-windows-remote-command
          then change that one to launch a 64 bit RemComSvc.exe when on 64 bit platforms.

          Jimmy Bergman added a comment - - edited The cause of this is: 1. The "Checking if Java exists" uses WindowsRemoteProcessLauncher, which executes code by installing a service running a 32 bit application, that in turn runs the requested commands 2. Windows 7 and Windows 2008 64 bit runs 32 bit apps in WOW64 compat mode, see http://serverfault.com/questions/208399/windows-7-system32-different-contents-depending-on-how-its-viewed 3. The newest version of java installs java.exe in c:\windows\system32 Workaround: copy c:\windows\system32\java.exe c:\windows\syswow64 But the real fix would be to either change algorithm for executing the command, or if continuing to use https://github.com/jenkinsci/lib-windows-remote-command then change that one to launch a 64 bit RemComSvc.exe when on 64 bit platforms.

          Garen Parham added a comment -

          I ran into this problem after jumping through all the hoops from the docs:

          https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service

          In my case, I have a Windows 7 64-bit master and slaves with 32-bit JRE installs of Java (via jre-6u30-windows-i586-s.exe). From the perspective of the master, the agent log shows (and never succeeds):

           
          Connecting to rtl-agent3
          Checking if Java exists
          java full version "1.6.0_30-b12"
          Installing the Jenkins slave service
          Copying jenkins-slave.exe
          Copying slave.jar
          Copying jenkins-slave.xml
          Registering the service
          Starting the service
          Waiting for the service to become ready
          ERROR: The service didn't respond. Perphaps it failed to launch?
          

          On the slave, the Event Viewer shows this error:

           
          Service cannot be started. System.ComponentModel.Win32Exception: The system cannot find the file specified
             at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
             at winsw.WrapperService.StartProcess(Process process, String arguments, String executable)
             at winsw.WrapperService.OnStart(String[] _)
             at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)
          

          Note that java.exe being accessible differs depending on the command prompt used is from C:\Windows\System32\cmd.exe (default) or C:\Windows\SysWOW64\cmd.exe like so:

          Microsoft Windows [Version 6.1.7601]
          Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
          
          C:\Windows\System32>cd\
          
          C:\>java -fullversion
          'java' is not recognized as an internal or external command,
          operable program or batch file.
          
          C:\>C:\Windows\System32\java.exe -fullversion
          'C:\Windows\System32\java.exe' is not recognized as an internal or external command,
          operable program or batch file.
          
          C:\>C:\Windows\SysWOW64\java.exe -fullversion
          java full version "1.6.0_30-b12"
          
          C:\>dir C:\Windows\System32\java*
           Volume in drive C has no label.
           Volume Serial Number is 2477-B9CD
          
           Directory of C:\Windows\System32
          
          File Not Found
          

          And with C:\Windows\SysWOW64\cmd.exe:

          Microsoft Windows [Version 6.1.7601]
          Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
          
          C:\Windows\SysWOW64>cd\
          
          C:\>java -fullversion
          java full version "1.6.0_30-b12"
          
          C:\>C:\Windows\System32\java.exe -fullversion
          java full version "1.6.0_30-b12"
          
          C:\>C:\Windows\SysWOW64\java.exe -fullversion
          java full version "1.6.0_30-b12"
          

          Note how in the 64-bit cmd.exe, java.exe is visible in both paths:

          C:\>dir C:\Windows\System32\java*
           Volume in drive C has no label.
           Volume Serial Number is 2477-B9CD
          
           Directory of C:\Windows\System32
          
          12/28/2011  03:26 PM           149,280 java.exe
          12/28/2011  03:26 PM           149,280 javaw.exe
          12/28/2011  03:26 PM           157,472 javaws.exe
                         3 File(s)        456,032 bytes
                         0 Dir(s)  19,640,827,904 bytes free
          
          C:\>dir C:\Windows\SysWOW64\java*
           Volume in drive C has no label.
           Volume Serial Number is 2477-B9CD
          
           Directory of C:\Windows\SysWOW64
          
          12/28/2011  03:26 PM           149,280 java.exe
          12/28/2011  03:26 PM           149,280 javaw.exe
          12/28/2011  03:26 PM           157,472 javaws.exe
                         3 File(s)        456,032 bytes
                         0 Dir(s)  19,640,827,904 bytes free
          

          Garen Parham added a comment - I ran into this problem after jumping through all the hoops from the docs: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service In my case, I have a Windows 7 64-bit master and slaves with 32-bit JRE installs of Java (via jre-6u30-windows-i586-s.exe). From the perspective of the master, the agent log shows (and never succeeds): Connecting to rtl-agent3 Checking if Java exists java full version "1.6.0_30-b12" Installing the Jenkins slave service Copying jenkins-slave.exe Copying slave.jar Copying jenkins-slave.xml Registering the service Starting the service Waiting for the service to become ready ERROR: The service didn't respond. Perphaps it failed to launch? On the slave, the Event Viewer shows this error: Service cannot be started. System.ComponentModel.Win32Exception: The system cannot find the file specified at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo) at winsw.WrapperService.StartProcess(Process process, String arguments, String executable) at winsw.WrapperService.OnStart(String[] _) at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state) Note that java.exe being accessible differs depending on the command prompt used is from C:\Windows\System32\cmd.exe (default) or C:\Windows\SysWOW64\cmd.exe like so: Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\System32>cd\ C:\>java -fullversion 'java' is not recognized as an internal or external command, operable program or batch file. C:\>C:\Windows\System32\java.exe -fullversion 'C:\Windows\System32\java.exe' is not recognized as an internal or external command, operable program or batch file. C:\>C:\Windows\SysWOW64\java.exe -fullversion java full version "1.6.0_30-b12" C:\>dir C:\Windows\System32\java* Volume in drive C has no label. Volume Serial Number is 2477-B9CD Directory of C:\Windows\System32 File Not Found And with C:\Windows\SysWOW64\cmd.exe: Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\SysWOW64>cd\ C:\>java -fullversion java full version "1.6.0_30-b12" C:\>C:\Windows\System32\java.exe -fullversion java full version "1.6.0_30-b12" C:\>C:\Windows\SysWOW64\java.exe -fullversion java full version "1.6.0_30-b12" Note how in the 64-bit cmd.exe, java.exe is visible in both paths: C:\>dir C:\Windows\System32\java* Volume in drive C has no label. Volume Serial Number is 2477-B9CD Directory of C:\Windows\System32 12/28/2011 03:26 PM 149,280 java.exe 12/28/2011 03:26 PM 149,280 javaw.exe 12/28/2011 03:26 PM 157,472 javaws.exe 3 File(s) 456,032 bytes 0 Dir(s) 19,640,827,904 bytes free C:\>dir C:\Windows\SysWOW64\java* Volume in drive C has no label. Volume Serial Number is 2477-B9CD Directory of C:\Windows\SysWOW64 12/28/2011 03:26 PM 149,280 java.exe 12/28/2011 03:26 PM 149,280 javaw.exe 12/28/2011 03:26 PM 157,472 javaws.exe 3 File(s) 456,032 bytes 0 Dir(s) 19,640,827,904 bytes free

          Oleg Nenashev added a comment -

          Closing as "Not a defect".
          The issue is quite painful, but it has been caused by the "as designed" Windows architecture

          Oleg Nenashev added a comment - Closing as "Not a defect". The issue is quite painful, but it has been caused by the "as designed" Windows architecture

          Ilguiz Latypov added a comment - - edited

          The "system cannot find the file specified" error results from the poor service wrapper architecture that freezes the java.exe location in the "executable" XML tag inside its jenkins-slave.xml.

          https://mohitgoyal.co/2016/12/18/failed-to-start-jenkins-after-updating-java/

           

          I also found that it helps to comment out the other tag enabling a live update of the slave JAR.  When this update is enabled, the service fails to start.  The wrapper log shows an attempt to download the file and timing out without giving a verbose reason for this.

           

          Ilguiz Latypov added a comment - - edited The "system cannot find the file specified" error results from the poor service wrapper architecture that freezes the java.exe location in the "executable" XML tag inside its jenkins-slave.xml. https://mohitgoyal.co/2016/12/18/failed-to-start-jenkins-after-updating-java/   I also found that it helps to comment out the other tag enabling a live update of the slave JAR.  When this update is enabled, the service fails to start.  The wrapper log shows an attempt to download the file and timing out without giving a verbose reason for this.  

            Unassigned Unassigned
            hhuynh hhuynh
            Votes:
            9 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: