Hudson Windows 服务从属启动导致 SmbException
我们刚刚为 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)
:问题可能是桑巴本身,而不是 Hudson。我们已经仔细检查了 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 客户端效果很好,尽管我们更希望将其作为服务。
顺便说一下,Hudson 版本是 1.323(只有一个落后,更新日志中看起来没有什么特别相关的)。
We just acquired three new build slaves for Hudson, which are running Windows XP x64. We're having issues deploying to these that we haven't seen before (we have two other XP32 machines already slaved).
When we first reboot the server, or just after restarting the Server service, the node's log on hudson shows the following (domain name changed to protect the innocent):
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)
On any subsequent attempts to "Launch slave service", we get:
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)
It seems like samba itself, not Hudson, may be the issue. We've double-checked group memberships and directory permissions for C:\hudson and they're identical to the other two slaves.
Using smbclient from the MacOSX server that's actually running Tomcat+Hudson (but does not execute builds), I was able to get a strange response on one attempt:
smb: \hudson\> get hudson-slave.exe NT_STATUS_INSUFF_SERVER_RESOURCES opening remote file \hudson\hudson-slave.exe
Googling around suggest an IRPStackSize issue might be the culprit, but jacking that up 5 at a time (eventually to 50 = 0x32) and restarting the Server service doesn't seem to help.
As an aside, launching JNLP client works just fine, although we'd prefer to have it as a service.
Hudson version is 1.323, by the way (only one behind, nothing in the changelog looks particularly relevant).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
看来 JCIFS 可能对此有解决方案。来自同事:
“刚刚查看了当前的 hudson 源代码,他们正在使用 jcifs-1.3.3,因此他们落后了并且没有此(以及其他几个)更新。”
我将考虑将其推送到上游错误跟踪器中,并可能尝试集成较新的版本并在本地重建。
更新 1:在此处提交问题跟踪器条目
更新 2:我们已切换到 JNLP 并使用它来安装一个服务,该服务设置为自动启动。这已经工作一两天了,没有出现离线问题。将继续关注上游错误,以查看那里是否/何时发生任何活动。
Looks like JCIFS may have a fix for this. From a coworker:
"Just looked at the current hudson source, they're using jcifs-1.3.3 so they are behind and do not have this (as well as several other) update(s)."
I'll see about pushing this into the upstream bug tracker, and perhaps give a shot at integrating the newer version and rebuilding locally.
Update 1: filed an issue tracker entry here
Update 2: we've switched over to JNLP and used that to install a service, which is set to automatically start. This has been working without offline issues for a day or two now. Will keep watching the upstream bug to see if/when any activity happens there.