Le lancement de l'esclave de service Hudson Windows provoque SmbException

Question

Nous venons d'acquérir trois nouveaux esclaves de construction pour Hudson, qui exécutent Windows XP x64. Nous avons des problèmes de déploiement de ces derniers que nous n'avons pas vu auparavant (nous avons déjà deux autres machines XP32 déjà esclaves).

Lorsque nous avons redémarrer le serveur, ou juste après le redémarrage du service Serveur, montre les éléments suivants (nom de domaine a été modifié pour protéger les innocents) le journal sur hudson du nœud:

 
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) 

Sur toutes les tentatives ultérieures de " Lancer le service esclave ", nous obtenons:

 
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) 

Il semble que samba lui-même, pas Hudson, peut-être le problème. Nous avons revérifié les appartenances aux groupes et les permissions de répertoire pour C: \ hudson et ils sont identiques aux deux autres esclaves.

En utilisant smbclient du MacOSX qui est en fait en cours d'exécution Tomcat + Hudson (mais n'exécute pas construit), j'ai pu obtenir une réponse étrange une tentative:

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

recherche sur Google propose autour d'une question IRPStackSize pourrait être le coupable, mais en le soulevant 5 à la fois (éventuellement à 50 = 0x32) et en redémarrant le service serveur ne semble pas aider. En outre, lancer le client JNLP fonctionne très bien, bien que nous préférerions l'avoir en tant que service. La version de Hudson est 1.323, en passant (seulement un derrière, rien dans le changelog semble particulièrement pertinent).

Answer 1

On dirait que JCIFS peut avoir un correctif pour cela. D'un collègue de travail:

 
"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." 

« Juste regardé à la source de hudson actuelle, ils utilisent jcifs-ils sont 1.3.3 derrière et n'ont pas (ainsi que plusieurs autres) mise à jour (s). "

Je verrais à propos de pousser cela dans le suivi des bugs en amont, et peut-être essayer d'intégrer la nouvelle version et de la reconstruire localement.

---

Mise à jour 1: a déposé une issue tracker entry here

---

Mise à jour 2: nous avons basculé sur JNLP et utilisé que pour installer un service, qui est configuré pour démarrer automatiquement. Cela a fonctionné sans problèmes hors ligne pendant un jour ou deux maintenant. Continuera à regarder le bogue en amont pour voir si/quand une activité s'y passe.