Hudson Windows-Dienst Slave-Start verursacht SmbException

Question

Wir erwarben nur drei Neubauten Sklaven für Hudson , die Windows XP x64 ausgeführt werden. Wir haben ein Problem auf diese bereitstellen, die wir vorher nicht gesehen haben (wir haben zwei weitere XP32 Maschinen bereits nachgeführt).

Als wir den Server neu starten, oder einfach nur nach den Server-Dienst neu zu starten, das Protokoll des Knotens auf hudson zeigt die folgende (Domain Name zum Schutz der Unschuldigen geändert):

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)

bei nachfolgenden Versuchen zu "Launch Slave-Service", erhalten wir:

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)

Es scheint, wie Samba selbst, nicht Hudson, kann das Problem sein. Wir haben doppelt überprüft Gruppenmitgliedschaften und Verzeichnisberechtigungen für C: \ hudson und sie sind identisch mit den beiden anderen Sklaven

.

Mit smbclient aus dem Mac OS X Server, die tatsächlich läuft Tomcat + Hudson ist (aber nicht ausführen baut), konnte ich eine seltsame Antwort auf einen Versuch bekommen:

smb: \hudson\> get hudson-slave.exe
NT_STATUS_INSUFF_SERVER_RESOURCES opening remote file \hudson\hudson-slave.exe

Googeln um vorschlagen IRPStackSize Problem könnte die Ursache sein, aber die 5 Aufbocken auf eine Zeit (schließlich zu 50 = 0x32) und den Server-Dienst neu zu starten scheint nicht zu helfen.

Als Neben JNLP-Client startet funktioniert gut, obwohl wir es als Dienst zu haben, würden es vorziehen.

---

Hudson Version 1.323, übrigens (nur hinter, nichts im Changelog besonders relevant aussieht).

Answer 1

Sieht aus wie JCIFS ein Update für diese haben können. Von einem Mitarbeiter:

"jcifs-1.3.10 released / Bugfix for SmbException: The parameter is incorrect
posted by Mike, June 4, 2009
This release fixes a bug that could sporadically trigger a "The parameter is incorrect" error." 

„sah sie nur an der aktuellen hudson Quelle, sind sie jCIFS-1.3.3 verwenden, so dass sie hinter sind und nicht über diese (wie auch einige andere) Update (s).“

Ich werde sehen, um diese in die Upstream-Bug-Tracker schieben, und vielleicht einen Schuss auf die neuere Version zu integrieren und den Wiederaufbau vor Ort.

---

Update 1: meldete issue tracker Eintrag hier

---

Update 2: Wir haben zu JNLP umgeschaltet und verwenden, die einen Dienst zu installieren, die automatisch gesetzt zu starten. Dies hat gearbeitet, ohne offline Themen für einen Tag oder zwei jetzt. Hält den Upstream-Bug beobachten, wenn / zu sehen, wenn jede Tätigkeit dort geschieht.