Hudson do Windows lançamento escravo serviço faz com que SmbException
Pergunta
Nós apenas adquiriu três novos escravos de construção para Hudson , que estão executando o Windows XP x64. Estamos tendo problemas de implantação para esses que nós não vimos antes (temos dois outros XP32 máquinas já escravo).
Quando começamos a reiniciar o servidor, ou apenas depois de reiniciar o serviço de servidor, o log do nó em programas de hudson o seguinte (nome de domínio alterado para proteger os inocentes):
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)
Em todas as tentativas subsequentes para "serviço de Lançamento escravo", obtemos:
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)
Parece que samba em si, não Hudson, pode ser o problema. Temos participações em grupos verificou duas vezes e permissões de diretório para C:. \ Hudson e eles são idênticos aos outros dois escravos
Usando smbclient do servidor MacOSX que está realmente correndo Tomcat + Hudson (mas não executa compilações), eu era capaz de obter uma resposta estranha em uma tentativa:
smb: \hudson\> get hudson-slave.exe NT_STATUS_INSUFF_SERVER_RESOURCES opening remote file \hudson\hudson-slave.exe
pesquisando por aí sugerem um problema IRPStackSize pode ser o culpado, mas jacking que até 5 de um tempo (eventualmente, para 50 = 0x32) e reiniciar o serviço de servidor não parece ajuda.
Como um aparte, o lançamento de cliente JNLP funciona muito bem, embora nós preferimos tê-lo como um serviço.
Versão Hudson é 1.323, pela maneira (apenas um por trás, nada nos olhares changelog particularmente relevantes).
Solução
Looks como JCIFS pode ter uma correção para isso. A partir de um colega de trabalho:
"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."
"Apenas olhou para a fonte hudson atual, eles estão usando JCIFS-1.3.3 que eles estão por trás e não tem isso (assim como vários outros) update (s)."
Vou ver sobre empurrar este para o bug tracker upstream, e talvez dar um tiro em integrar a versão mais recente e reconstrução local.
Update 1: interpôs href="https://hudson.dev.java.net/issues/show_bug.cgi?id=4564" rel="nofollow noreferrer"> entrada rastreador
Update 2: nós comutada para JNLP e usou isso para instalar um serviço, que é definido para iniciar automaticamente. Este tem vindo a trabalhar sem problemas offline para um ou dois dias agora. Vai continuar assistindo o bug upstream para ver se / quando qualquer atividade acontece lá.