【发布时间】:2010-12-01 12:27:57
【问题描述】:
我们刚刚为Hudson 购买了三个新的构建从属服务器,它们运行的是 Windows XP x64。我们在部署到这些之前从未见过的问题(我们有另外两台 XP32 机器已经从属)。
当我们第一次重启服务器,或者刚刚重启Server服务后,节点在hudson上的登录显示如下(域名改了保护无辜):
连接到 beast.example.com 复制slave.jar 参数不正确。 jcifs.smb.SmbException:参数不正确。 在 jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:542) 在 jcifs.smb.SmbTransport.send(SmbTransport.java:644) 在 jcifs.smb.SmbSession.sessionSetup(SmbSession.java:371) 在 jcifs.smb.SmbSession.send(SmbSession.java:235) 在 jcifs.smb.SmbTree.treeConnect(SmbTree.java:161) 在 jcifs.smb.SmbFile.doConnect(SmbFile.java:858) 在 jcifs.smb.SmbFile.connect(SmbFile.java:901) 在 jcifs.smb.SmbFile.connect0(SmbFile.java:827) 在 jcifs.smb.SmbFile.open0(SmbFile.java:917) 在 jcifs.smb.SmbFile.open(SmbFile.java:951) 在 jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:142) 在 jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:97) 在 jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:67) 在 jcifs.smb.SmbFile.getOutputStream(SmbFile.java:2793) 在 hudson.os.windows.ManagedWindowsServiceLauncher.copySlaveJar(ManagedWindowsServiceLauncher.java:198) 在 hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:152) 在 hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:175) 在 java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) 在 java.util.concurrent.FutureTask.run(FutureTask.java:123) 在 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676) 在 java.lang.Thread.run(Thread.java:613)在任何后续尝试“启动从服务”时,我们得到:
连接到 beast.example.com 复制slave.jar 0xC0000205 jcifs.smb.SmbException: 0xC0000205 在 jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:542) 在 jcifs.smb.SmbTransport.send(SmbTransport.java:644) 在 jcifs.smb.SmbSession.send(SmbSession.java:242) 在 jcifs.smb.SmbTree.send(SmbTree.java:111) 在 jcifs.smb.SmbFile.send(SmbFile.java:729) 在 jcifs.smb.SmbFile.open0(SmbFile.java:934) 在 jcifs.smb.SmbFile.open(SmbFile.java:951) 在 jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:142) 在 jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:97) 在 jcifs.smb.SmbFileOutputStream.(SmbFileOutputStream.java:67) 在 jcifs.smb.SmbFile.getOutputStream(SmbFile.java:2793) 在 hudson.os.windows.ManagedWindowsServiceLauncher.copySlaveJar(ManagedWindowsServiceLauncher.java:198) 在 hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:152) 在 hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:175) 在 java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) 在 java.util.concurrent.FutureTask.run(FutureTask.java:123) 在 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676) 在 java.lang.Thread.run(Thread.java:613)似乎是 samba 本身,而不是 Hudson,可能是问题所在。我们仔细检查了 C:\hudson 的组成员身份和目录权限,它们与其他两个从属服务器相同。
使用实际运行 Tomcat+Hudson(但不执行构建)的 MacOSX 服务器上的 smbclient,我一次尝试就得到了奇怪的响应:
smb: \hudson\> 获取 hudson-slave.exe NT_STATUS_INSUFF_SERVER_RESOURCES 打开远程文件 \hudson\hudson-slave.exe谷歌搜索表明IRPStackSize 问题可能是罪魁祸首,但一次增加 5 个(最终达到 50 = 0x32)并重新启动服务器服务似乎没有帮助。
顺便说一句,启动 JNLP 客户端效果很好,尽管我们更愿意将其作为服务提供。
顺便说一下,Hudson 版本是 1.323(仅落后一个,更新日志中没有任何内容看起来特别相关)。
【问题讨论】: