./executable: não é possível executar o arquivo binário

Question

Eu tenho um script que funciona bem quando eu ssh para o servidor para executá-lo sozinho, mas tem problemas quando Hudson , uma integração contínua servidor, executa-o.

Eu estou automatizando testes em um sistema Linux embutido (o alvo). O alvo é conectado ao Servidor A (RHEL 5) via serial e operado por minicom. O Servidor B (FC 12) constrói os testes que realmente são executados no destino e pode ssh para o Servidor A. O Servidor C (RH) hospeda o Hudson, com o Servidor B como escravo.

Eu escrevi um script runcript (http://linux.die.net/man/1/runscript) para fazer tudo o que é necessário no alvo real; Ele inicializa a imagem, monta um diretório do Servidor B e executa os testes. Um script bash no Servidor B invoca o minicom com o script runscript juntamente com algumas ações complementares. Eu tenho um script bash no servidor B, que usa

ssh -t -t ServerA bashScript.sh

para que esses testes sejam executados no destino. Eu estou no Servidor C, posso fazer com que esses testes sejam executados pelo ssh'ing para o Servidor B e executar o script que o ssh para o Servidor A que executa o minicom com o runscript. Whew. Para rever:

Servidor A: O Hudson usa seu mecanismo escravo para ssh para o Servidor B.

Servidor B: kickOffTests.sh tem a linha ssh -t -t ServerA runTests.sh

Servidor A: runTests.sh chama um script perl que chama minicom -S my.script ttyE1

Destino, após a inicialização: Monta um diretório do Servidor B, onde estão os testes, e entra nesse diretório. Invoca ainda outro script bash, que executa os testes, que são executáveis C compilados.

Agora, quando eu executo qualquer um desses scripts, eles fazem o que devem. No entanto, quando Hudson tenta fazer a mesma coisa, na sessão do minicom ele reclama de uma linha no "outro script bash" que chama o executável C, ./executable , com ./executable: cannot execute binary file

Eu ainda tenho muito a aprender sobre o Linux, mas eu suponho que esse problema é resultado do Hudson não se conectar com um console. Eu não sei exatamente o que Hudson faz para controlar seu escravo. Eu tentei usar a linha export TERM=console na configuração antes de executar kickOffTests.sh, mas o problema continua.

Alguém pode me explicar o que está acontecendo e como posso corrigi-lo? Não consigo remover nenhum dos servidores dessa equação. Pode ser possível tirar o minicom da equação, mas isso adicionaria uma quantidade desconhecida de tempo a este projeto, então eu preferiria muito mais uma solução que use o que eu já tenho.

    

Answer 1

A mensagem cannot execute binary file não tem nada a ver com terminais (eu me pergunto o que te levou a pensar isso - e eu recomendo evitar fazer tais suposições em uma questão, já que elas tendem a afogar seu problema real em uma confusão de pistas falsas) . Na verdade, é a maneira como o bash expressa ENOEXEC (mais comumente expresso como exec format error .

Primeiro, certifique-se de que você não tenha tentado acidentalmente executar esse executável como um script. Se você escreveu . ./executable , isso diz ao bash para executar ./executable no mesmo ambiente que o script de chamada (em oposição a um processo separado). Isso não pode ser feito se o arquivo não for um script.

Caso contrário, esta mensagem significa que ./executable não está em um formato que o kernel reconheça. Eu não tenho nenhum palpite definitivo sobre o que está acontecendo. Se você puder executar o script na mesma máquina invocando-o de uma maneira diferente, ele não poderá ser apenas um arquivo corrompido ou um arquivo para a arquitetura incorreta (pode ser que, mas há mais). Pergunto-me se poderia haver uma diferença na forma como o alvo inicia (talvez uma condição de corrida).

Veja uma lista de dados adicionais que podem ajudar:

• Saída de file …/executable no servidor B.
• Algumas informações sobre o destino, como a saída de uname -a , se for do tipo unix.
• Verifique se o destino vê o mesmo conteúdo de arquivo a cada vez: execute cksum ./executable ou md5sum ./executable ou qualquer método que você tenha no destino antes de ainda-outro-bash-script invocar ./executable . Verifique se os resultados são os mesmos na chamada de Hudson, na sua invocação manual bem-sucedida e no servidor B.
• Adicione set -x na parte superior do script yet-another-bash (logo abaixo da linha #!/bin/bash ). Isso produzirá um rastro de tudo o que o script faz. Compare os traços e relate qualquer diferença ou esquisitice.
• Descreva como o alvo está inicializando quando você executa os scripts manualmente e quando o Hudson está envolvido. Pode ser que o destino seja inicializado de forma diferente e algum módulo carregável que forneça o suporte para o formato de ./executable não seja carregado (ou não seja carregado ainda) nas chamadas do Hudson. Você pode querer usar set -x em outros scripts para ajudá-lo lá e inspecionar os logs de inicialização do destino.

Answer 2

Isso pode acontecer se você não tiver a linha shebang no topo do seu script. Certifique-se de que o script comece com:

#!/bin/bash

Isso só apareceu para mim quando executei o script com sudo -u <user>