"exec format error" e "cannot execute binary file": incompatibilidades de arquitetura e de shebang

O que é

Este é o erro ENOEXEC do kernel, retornado por execve(2); a página de manual o descreve como um executável cujo formato é reconhecido mas não suportado, ou que não tem formato algum. O Bash o reporta como cannot execute binary file: Exec format error; o Docker/runc atual, como exec /usr/local/bin/app: exec format error (versões mais antigas: standard_init_linux.go:NNN: exec user process caused: exec format error); o Python, como OSError: [Errno 8] Exec format error. Duas causas produzem esse erro, e uma terceira, relacionada, falha com uma mensagem diferente:

• Incompatibilidade de arquitetura: um binário ELF compilado para uma arquitetura de CPU (arm64, por exemplo) é executado em hardware de outra (amd64) sem um emulador registrado via binfmt_misc.
• Shebang ausente ou malformado: o script não tem uma primeira linha #!interpreter, ou algo (como um BOM UTF-8) vem antes dela. Um shell interativo esconde esse caso executando o próprio arquivo como script de shell; qualquer coisa que chame execve diretamente (o entrypoint de um contêiner, uma chamada de subprocesso) recebe ENOEXEC.
• Finais de linha CRLF no shebang: o carriage return no final passa a fazer parte do caminho do interpretador, o kernel retorna ENOENT em vez disso e a mensagem depende do shell: o bash 5.1 e anteriores (e o 5.3) exibem /bin/bash^M: bad interpreter: No such file or directory, o bash 5.2 exibe cannot execute: required file not found, e uma linha #!/usr/bin/env bash resulta em /usr/bin/env: 'bash\r': No such file or directory.

Por que importa

Os três casos são comuns em trabalho multiplataforma: baixar uma imagem de contêiner construída para uma arquitetura diferente da do host, copiar scripts entre sistemas operacionais ou gerar um script com uma ferramenta que grava CRLF por padrão. A mensagem curta não diz qual das causas se aplica.

Como aplicar

• Diagnostique primeiro: file ./target informa a arquitetura do ELF ("ELF 64-bit LSB executable, ARM aarch64") ou, no caso de um script, se ele tem terminadores CRLF. Compare a arquitetura do ELF com a saída de uname -m no host, ou com a plataforma de destino de um contêiner usando docker image inspect <image> --format '{{.Architecture}}'.
• Correções, da menos para a mais invasiva:
  1. Shebang com CRLF: remova os carriage returns, por exemplo com sed -i 's/\r$//' script.sh ou dos2unix script.sh.
  2. Shebang ausente ou corrompido: adicione uma primeira linha correta, por exemplo #!/usr/bin/env bash.
  3. Incompatibilidade de arquitetura em contêineres: peça a plataforma correta de forma explícita, com docker run --platform linux/amd64 ..., ou construa para várias plataformas com docker buildx build --platform linux/amd64,linux/arm64 ..., como descreve a documentação de builds multiplataforma do Docker.
  4. Recompile o binário nativamente para a arquitetura de destino, em vez de depender de emulação, principalmente em tudo o que for sensível a desempenho.
• Não resolve: chmod +x sozinho não faz nada diante de uma incompatibilidade de formato ou de arquitetura, embora valha a pena descartá-lo à parte, já que a falta do bit de execução produz outra mensagem ("Permission denied").

Armadilhas

• Presumir que a mensagem sempre significa "arquitetura errada" e recompilar sem necessidade, quando a causa real é um shebang com CRLF.
• Testar uma imagem arm64 em amd64 sob emulação QEMU e concluir que está tudo certo: a emulação é lenta e tem bugs próprios, portanto passar nesse teste não prova que a imagem se comporta da mesma forma em hardware arm64 real.