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

Foi útil?

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

scroll top