[JIRA] (JENKINS-6957) Windows slave fails to find java
jimmy@sigint.se (JIRA)
[ https://issues.jenkins-ci.org/browse/JENKINS-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=154894#comment-154894 ]
Jimmy Bergman commented on JENKINS-6957:
----------------------------------------
The cause of this is:
1. The "Checking if Java exists" uses TestWindowsRemoteProcessLauncher, 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.
> Windows slave fails to find java
> --------------------------------
>
> Key: JENKINS-6957
> URL: https://issues.jenkins-ci.org/browse/JENKINS-6957
> Project: Jenkins
> Issue Type: Bug
> Components: core
> Affects Versions: current
> Reporter: hhuynh
>
> 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.
> {noformat}
> 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
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
jimmy@sigint.se (JIRA)
[ https://issues.jenkins-ci.org/browse/JENKINS-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=154894#comment-154894 ]
Jimmy Bergman edited comment on JENKINS-6957 at 11/3/11 12:51 PM:
------------------------------------------------------------------
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.
was (Author: jimmybergman):