«exec format error» y «cannot execute binary file»: incompatibilidades de arquitectura y de shebang

Qué es

Es el error ENOEXEC del kernel, devuelto por execve(2); su página de manual lo describe como un ejecutable cuyo formato es reconocido pero no soportado, o que no tiene formato alguno. Bash lo muestra como cannot execute binary file: Exec format error; las versiones actuales de Docker/runc, como exec /usr/local/bin/app: exec format error (en versiones anteriores: standard_init_linux.go:NNN: exec user process caused: exec format error); Python, como OSError: [Errno 8] Exec format error. Dos causas producen este error, y una tercera, relacionada, falla con un mensaje distinto:

• Incompatibilidad de arquitectura: un binario ELF compilado para una arquitectura de CPU (por ejemplo, arm64) se ejecuta en hardware de otra (amd64) sin un emulador registrado mediante binfmt_misc.
• Shebang ausente o mal formado: el script no tiene una primera línea #!interpreter, o algo (como una marca de orden de bytes UTF-8) la precede. Un shell interactivo oculta este caso porque ejecuta el archivo él mismo como script de shell; todo lo que llama directamente a execve (el entrypoint de un contenedor, una llamada a un subproceso) recibe ENOEXEC.
• Saltos de línea CRLF en el shebang: un retorno de carro final pasa a formar parte de la ruta del intérprete, el kernel devuelve ENOENT en su lugar y el texto del mensaje depende del shell: bash 5.1 y anteriores (y 5.3) muestran /bin/bash^M: bad interpreter: No such file or directory, bash 5.2 muestra cannot execute: required file not found, y una línea #!/usr/bin/env bash produce /usr/bin/env: 'bash\r': No such file or directory.

Por qué importa

Los tres casos son habituales en el trabajo multiplataforma: descargar una imagen de contenedor construida para una arquitectura distinta de la del host, copiar scripts entre sistemas operativos o generar un script con una herramienta que escribe CRLF por defecto. El mensaje, escueto, no indica cuál de las causas es la que aplica.

Cómo aplicarlo

• Diagnostica primero: file ./target indica la arquitectura del ELF («ELF 64-bit LSB executable, ARM aarch64») o, en el caso de un script, si tiene terminadores CRLF. Compara la arquitectura de un ELF con uname -m en el host, o con la plataforma de destino de un contenedor mediante docker image inspect <image> --format '{{.Architecture}}'.
• Soluciones, de la menos a la más invasiva:
  1. Shebang con CRLF: elimina los retornos de carro, por ejemplo con sed -i 's/\r$//' script.sh o dos2unix script.sh.
  2. Shebang ausente o corrupto: añade una primera línea correcta, por ejemplo #!/usr/bin/env bash.
  3. Incompatibilidad de arquitectura en contenedores: solicita explícitamente la plataforma correcta con docker run --platform linux/amd64 ..., o construye para varias plataformas con docker buildx build --platform linux/amd64,linux/arm64 ..., tal como describe la documentación de Docker sobre compilaciones multiplataforma.
  4. Recompila el binario de forma nativa para la arquitectura de destino en lugar de depender de la emulación, sobre todo en todo aquello sensible al rendimiento.
• Lo que no es una solución: chmod +x por sí solo no resuelve una incompatibilidad de formato o de arquitectura, aunque conviene descartarlo por separado, ya que la falta del bit de ejecución produce un mensaje distinto («Permission denied»).

Trampas

• Dar por hecho que el mensaje siempre significa «arquitectura incorrecta» y recompilar sin necesidad cuando la causa real es un shebang con CRLF.
• Probar una imagen arm64 en amd64 con emulación QEMU y concluir que funciona correctamente: la emulación es lenta y tiene sus propios errores, de modo que superar la prueba así no demuestra que la imagen se comporte igual en hardware arm64 real.