DEV Community

Erick Eduardo Ramos
Erick Eduardo Ramos

Posted on

Cómo solucionar `Code exited (1)` en Docker en Raspberry Pi

#devops #docker #linux #raspberrypi

Cómo solucionar Code exited (1) en Docker en Raspberry Pi

¿Por qué ocurre este error?

El código de salida 1 indica que el proceso principal del contenedor (PID 1) terminó con un error. En Raspberry Pi, los casos más comunes son:

  • Arquitectura incompatible: La imagen se construyó para amd64 pero se ejecuta en ARM (armv7l o aarch64).
  • Falta de binario ejecutable: El ENTRYPOINT o CMD de la imagen no existe o no tiene permisos de ejecución.
  • Faltan dependencias del sistema: Librerías compartidas (libc, libstdc++, etc.) no disponibles en el entorno ARM.
  • Problemas de permisos en dispositivos físicos: Acceso a GPIO, I2C, SPI, etc., sin los privilegios adecuados.

⚠️ Nota crítica: El comando docker run --net = host tiene un error de sintaxis: los espacios alrededor del = son inválidos. Debe ser --net=host.

Pasos para diagnosticar y solucionar

1. Verifica el código de error real (sin -d)

Ejecuta el contenedor en primer plano para ver el error en tiempo real:

docker run --net=host -it --rm myimage
Enter fullscreen mode Exit fullscreen mode

Si el contenedor se cierra inmediatamente, este paso mostrará el mensaje de error real (ej: exec format error, No such file or directory, etc.).

2. Confirma la arquitectura del contenedor y del host 

# En tu Raspberry Pi:
uname -m  # Ej: armv7l o aarch64

# En la imagen (si puedes ejecutarla en modo interactivo):
docker run --rm -it myimage uname -m
Enter fullscreen mode Exit fullscreen mode

Si el resultado no coincide (ej: x86_64 vs armv7l), la imagen no es compatible.

3. Reconstruye la imagen para ARM (solución definitiva)

Opción A: Usa buildx para multiarquitectura 

# Crea un builder con soporte multiarquitectura
docker buildx create --use --name mybuilder

# Construye e impulsa una imagen compatible con ARM
docker buildx build \
  --platform linux/arm/v7,linux/arm64 \
  --push \
  -t tu-usuario/myimage:latest \
  .
Enter fullscreen mode Exit fullscreen mode

Opción B: Construye directamente en Raspberry Pi 

# Si no tienes acceso a x86, construye directamente en la Pi:
docker build -t myimage .
Enter fullscreen mode Exit fullscreen mode

🔧 Recomendación: Usa un Dockerfile con base compatible con ARM (ej: arm32v7/debian:bullseye o balenalib/raspberry-pi-python:3.9-bullseye).

4. Verifica el ENTRYPOINT y CMD

Revisa tu Dockerfile:

# ❌ Incorrecto: Ruta relativa o binario no existente
CMD ["./start.sh"]

# ✅ Correcto: Ruta absoluta y binario existente
CMD ["/usr/local/bin/start.sh"]
Enter fullscreen mode Exit fullscreen mode

Asegúrate de que:

  • El binario sea compatible con ARM.
  • Tenga permisos de ejecución (chmod +x).
  • Las dependencias dinámicas estén instaladas (ej: apt-get install -y libglib2.0-0).

5. Solución rápida para pruebas (no productiva)

Si solo necesitas ejecutar una imagen amd64 en ARM (ej: para emulación):

docker run --net=host --platform linux/amd64 -d -t myimage
Enter fullscreen mode Exit fullscreen mode

⚠️ Requiere QEMU y emulación lenta. Solo para pruebas.

Bloque de código corregido 

# Comando corregido (sin espacios en --net)
docker run --net=host -d -t myimage

# Si falla, ejecuta en primer plano para debug
docker run --net=host -it --rm myimage

# Ver logs si ya se ejecutó en segundo plano
docker logs <container_id>
Enter fullscreen mode Exit fullscreen mode

Pro-tip: Diagnóstico rápido con strace

Si el binario es tuyo y puedes modificar el Dockerfile, incluye strace para rastrear fallos:

RUN apt-get update && apt-get install -y strace
ENTRYPOINT ["strace", "-f", "-o", "/tmp/strace.log", "/tu/binario"]
Enter fullscreen mode Exit fullscreen mode

Luego revisa el log:

docker run --net=host myimage
docker cp <container_id>:/tmp/strace.log ./strace.log
Enter fullscreen mode Exit fullscreen mode

Esto revelará exactamente dónde falla el proceso (ej: open("/lib/libfoo.so") failed).

Top comments (0)