DEV Community

Erick Eduardo Ramos
Erick Eduardo Ramos

Posted on

Cómo solucionar `docker run` con `Exited (1)` en Raspberry Pi

Cómo solucionar docker run con Exited (1) en Raspberry Pi

Explicación técnica

El error Exited (1) indica que el proceso principal del contenedor terminó con un código de salida distinto de cero, lo que significa un fallo. En Raspberry Pi, este problema es muy frecuente y tiene causas específicas:

  1. Arquitectura incompatible: La imagen myimage fue construida para amd64 (x86_64), pero Raspberry Pi usa arm32v7 o arm64v8.
  2. Falta de binarios estáticos o dependencias faltantes: Algunas imágenes no incluyen todas las librerías necesarias para ARM.
  3. Problemas con --net=host en sistemas con systemd-resolved: En Raspbian, el puerto 53 está ocupado por systemd-resolved, causando fallos en contenedores que intentan usarlo.
  4. Falta de flags requeridos para ARM: Algunos contenedores requieren flags adicionales como --privileged o --cap-add=SYS_PTRACE.

Pasos para diagnosticar y solucionar

Paso 1: Verifica la arquitectura del host y la imagen

# Verifica arquitectura del Raspberry Pi
uname -m

# Verifica arquitectura de la imagen
docker inspect myimage --format '{{.Architecture}}'
Enter fullscreen mode Exit fullscreen mode

Si la imagen muestra amd64 y tu Raspberry Pi es armv7l o aarch64, ese es el problema.

Paso 2: Ejecuta en primer plano para ver el error real

docker run --net=host -t myimage
# NOTA: Quita -d para ver logs en tiempo real
Enter fullscreen mode Exit fullscreen mode

Paso 3: Soluciones según el caso

🔧 Caso A: Arquitectura incompatible (90% de los casos en Raspberry Pi)

Solución definitiva: Usa imágenes nativas para ARM o reconstruye la imagen.

# Opción 1: Usa imágenes oficiales con soporte multi-arch
docker run --net=host -d arm32v7/nginx:latest
# o para Raspberry Pi 4/400 (64-bit)
docker run --net=host -d arm64v8/nginx:latest

# Opción 2: Construye la imagen con QEMU para emulación (si no tienes alternativa)
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
docker buildx create --use --name mybuilder
docker buildx build --platform linux/arm/v7 -t myimage:armv7 --load .
Enter fullscreen mode Exit fullscreen mode

🔧 Caso B: Fallo por --net=host en Raspbian

# Detén systemd-resolved temporalmente
sudo systemctl stop systemd-resolved

# O usa bridge networking en su lugar
docker run --net=bridge -p 80:80 -d myimage
Enter fullscreen mode Exit fullscreen mode

🔧 Caso C: Falta de permisos o dependencias

# Agrega flags comunes para Raspberry Pi
docker run --net=host --privileged --cap-add=SYS_PTRACE -d myimage

# O si usas Docker Compose:
version: '3'
services:
  app:
    image: myimage
    network_mode: "host"
    privileged: true
    cap_add:
      - SYS_PTRACE
Enter fullscreen mode Exit fullscreen mode

Bloque de código corregido (ejemplo funcional)

# 1. Verifica arquitectura
uname -m  # Debe coincidir con la arquitectura de la imagen

# 2. Si es incompatible, usa una imagen ARM
docker pull arm32v7/alpine:latest
docker run --rm -it arm32v7/alpine sh

# 3. Para tu imagen personalizada (reconstruida para ARM):
docker buildx build --platform linux/arm/v7 -t myimage:armv7 --load .
docker run --net=host -d myimage:armv7
Enter fullscreen mode Exit fullscreen mode

Pro-tip

  • Siempre usa docker logs <container_id> después de un Exited (1) para ver el mensaje de error real.
  • En Raspberry Pi 4 con Raspberry Pi OS 64-bit, usa imágenes arm64v8 en lugar de arm32v7.
  • Para desarrollo rápido, añade -it en lugar de -d para ver errores en tiempo real:
  docker run --net=host -it myimage
Enter fullscreen mode Exit fullscreen mode
  • Verifica espacio en disco: df -h /var/lib/docker — Raspberry Pi suele tener poco espacio y Docker falla silenciosamente.

⚠️ Nota crítica: El error Exited (1) nunca es un bug de Docker. Siempre es un problema en la aplicación o entorno del contenedor. El código de salida 1 es genérico: el verdadero diagnóstico está en los logs.

Top comments (0)