我们刚刚获得了三个新的奴隶
Hudson
,运行的是Windows XP x64。我们在部署这些之前从未见过的设备时遇到问题(我们还有另外两台XP32机器已经解决了)。
当我们第一次重新启动服务器时,或者在重新启动服务器服务之后,节点的登录Hudson显示以下信息(域名已更改以保护无辜者):
Connecting to beast.example.com
Copying slave.jar
The parameter is incorrect.
jcifs.smb.SmbException: The parameter is incorrect.
at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:542)
at jcifs.smb.SmbTransport.send(SmbTransport.java:644)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:371)
at jcifs.smb.SmbSession.send(SmbSession.java:235)
at jcifs.smb.SmbTree.treeConnect(SmbTree.java:161)
at jcifs.smb.SmbFile.doConnect(SmbFile.java:858)
at jcifs.smb.SmbFile.connect(SmbFile.java:901)
at jcifs.smb.SmbFile.connect0(SmbFile.java:827)
at jcifs.smb.SmbFile.open0(SmbFile.java:917)
at jcifs.smb.SmbFile.open(SmbFile.java:951)
at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:142)
at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:97)
at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:67)
at jcifs.smb.SmbFile.getOutputStream(SmbFile.java:2793)
at hudson.os.windows.ManagedWindowsServiceLauncher.copySlaveJar(ManagedWindowsServiceLauncher.java:198)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:152)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:175)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:613)
在随后的“启动从属服务”尝试中,我们得到:
Connecting to beast.example.com
Copying slave.jar
0xC0000205
jcifs.smb.SmbException: 0xC0000205
at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:542)
at jcifs.smb.SmbTransport.send(SmbTransport.java:644)
at jcifs.smb.SmbSession.send(SmbSession.java:242)
at jcifs.smb.SmbTree.send(SmbTree.java:111)
at jcifs.smb.SmbFile.send(SmbFile.java:729)
at jcifs.smb.SmbFile.open0(SmbFile.java:934)
at jcifs.smb.SmbFile.open(SmbFile.java:951)
at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:142)
at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:97)
at jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:67)
at jcifs.smb.SmbFile.getOutputStream(SmbFile.java:2793)
at hudson.os.windows.ManagedWindowsServiceLauncher.copySlaveJar(ManagedWindowsServiceLauncher.java:198)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:152)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:175)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:613)
似乎桑巴本身,而不是哈德逊,可能是问题所在。我们已经对C:\Hudson的组成员身份和目录权限进行了双重检查,它们与其他两个从系统相同。
使用运行Tomcat+Hudson(但不执行构建)的MacOSX服务器上的smbclient,我可以在一次尝试中得到一个奇怪的响应:
smb: \hudson\> get hudson-slave.exe
NT_STATUS_INSUFF_SERVER_RESOURCES opening remote file \hudson\hudson-slave.exe
谷歌搜索建议
IRPStackSize
问题可能是罪魁祸首,但一次提高5(最终达到50=0x32)并重新启动服务器服务似乎没有帮助。
顺便说一句,启动JNLP客户机工作得很好,尽管我们更愿意将它作为一种服务。
顺便说一下,哈德逊版本是1.323(后面只有一个版本,changelog中没有任何内容看起来特别相关)。
