it-swarm-es.tech

./executable: no se puede ejecutar el archivo binario

Tengo un script que funciona bien cuando ssh al servidor para ejecutarlo yo mismo, pero tiene problemas cuando Hudson , un servidor de integración continua, lo ejecuta.

Estoy automatizando las pruebas en un sistema Linux integrado (el objetivo). El objetivo está conectado al Servidor A (RHEL 5) a través de serie y operado a través de minicom. El servidor B (FC 12) construye las pruebas que realmente se ejecutan en el destino y puede enviar ssh al servidor A. El servidor C (RH) aloja Hudson, con el servidor B como esclavo.

He escrito un script de runcript (http://linux.die.net/man/1/runscript) para hacer todo lo necesario en el objetivo real; inicia la imagen, monta un directorio desde el Servidor B y ejecuta las pruebas. Un script bash en el Servidor B invoca a minicom con el script runcript junto con algunas acciones complementarias. Tengo un script bash en el Servidor B que usa

ssh -t -t ServerA bashScript.sh

para ejecutar esas pruebas en el objetivo. Estoy en el Servidor C, puedo hacer que esas pruebas se ejecuten enviando ssh' al Servidor B y ejecutando el script que ssh's al Servidor A que ejecuta minicom con runcript. Whew. Para revisar:

Servidor A: Hudson usa su mecanismo esclavo para enviar ssh al Servidor B.

Servidor B: kickOffTests.sh tiene la línea ssh -t -t ServerA runTests.sh

Servidor A: runTests.sh llama a un script de Perl que invoca minicom -S my.script ttyE1

Destino, después del arranque: Monta un directorio desde el Servidor B, donde están las pruebas, y entra en ese directorio. Invoca otro script bash, que ejecuta las pruebas, que son compilados en C ejecutables.

Ahora, cuando [~ # ~] i [~ # ~] ejecuto cualquiera de estos scripts, hacen lo que deberían. Sin embargo, cuando Hudson intenta hacer lo mismo, en la sesión de minicom se queja de una línea en "otro script bash" que invoca el ejecutable C, ./executable, con ./executable: cannot execute binary file

Todavía tengo mucho que aprender sobre Linux, pero supongo que este problema es el resultado de que Hudson no se conecta con una consola. No sé exactamente qué hace Hudson para controlar a su esclavo. Traté de usar la línea export TERM=console en la configuración justo antes de ejecutar kickOffTests.sh, pero el problema persiste.

¿Alguien puede explicarme qué está sucediendo y cómo puedo solucionarlo? No puedo eliminar ninguno de los servidores de esta ecuación. Es posible eliminar minicom de la ecuación, pero eso agregaría una cantidad de tiempo desconocida a este proyecto, por lo que preferiría una solución que use lo que ya tengo.

12
jasper77

El mensaje cannot execute binary file no tiene nada que ver con los terminales (me pregunto qué lo llevó a pensar eso, y recomiendo evitar hacer tales suposiciones en una pregunta, ya que tienden a ahogar su problema real en un lío de pistas falsas). De hecho, es la forma en que bash expresa ENOEXEC (más comúnmente expresada como exec format error.

Primero, asegúrese de no haber intentado accidentalmente ejecutar este ejecutable como un script. Si escribiste . ./executable, esto le dice a bash que ejecute ./executable en el mismo entorno que el script de llamada (en oposición a un proceso separado). Eso no se puede hacer si el archivo no es un script.

De lo contrario, este mensaje significa que ./executable no está en un formato que el núcleo reconozca. Sin embargo, no tengo ninguna suposición definitiva sobre lo que está sucediendo. Si puede ejecutar el script en esa misma máquina invocandolo de una manera diferente, no puede ser solo un archivo corrupto o un archivo para la arquitectura incorrecta (puede ser eso, pero hay más). Me pregunto si podría haber una diferencia en la forma en que el objetivo arranca (quizás una condición de carrera).

Aquí hay una lista de datos adicionales que pueden ayudar:

  • Salida de file …/executable en el servidor B.
  • Alguna información sobre el objetivo, como la salida de uname -a si es como unix.
  • Verifique que el destino vea el mismo contenido de archivo cada vez: ejecute cksum ./executable o md5sum ./executable o cualquier método que tenga en el destino justo antes de que invoque otra secuencia de comandos bash ./executable. Verifique que los resultados sean los mismos en la invocación de Hudson, en su invocación manual exitosa y en el servidor B.
  • Añadir set -x en la parte superior de yet-another-bash-script (justo debajo de #!/bin/bash línea). Esto producirá un rastro de todo lo que hace el script. Compare los rastros e informe cualquier diferencia u rareza.
  • Describa cómo se inicia el destino cuando ejecuta los scripts manualmente y cuando Hudson está involucrado. Podría ser que el destino se inicie de manera diferente y algún módulo cargable que brinde soporte para el formato de ./executable no se carga (o aún no se carga) en las invocaciones de Hudson. Es posible que desee utilizar set -x en otros scripts para ayudarlo allí, e inspeccione los registros de arranque desde el objetivo.

Esto puede suceder si te falta la línea Shebang en la parte superior de tu script. Asegúrese de que el script comience con:

#!/bin/bash

Esto solo apareció para mí cuando ejecuté el script con Sudo -u <user>

0
Kevin Lamse