Cómo Solucionar el Error “OCI runtime create failed” de Docker [Guía Actualizada 2026]

スポンサーリンク

Cómo Solucionar el Error “OCI runtime create failed” de Docker [Guía Actualizada 2026]

¿Alguna vez ha encontrado el error “Error response from daemon: OCI runtime create failed” al intentar iniciar un contenedor Docker? Este error indica que el runtime de bajo nivel de Docker (runc) no pudo iniciar el contenedor. En este artículo, explicaremos detalladamente las causas y soluciones específicas para este error basándonos en la información más reciente de 2026.

¿Qué es este error? Síntomas que puede experimentar

El error “OCI runtime create failed” ocurre cuando Docker intenta crear e iniciar un contenedor utilizando un runtime compatible con OCI (Open Container Initiative). OCI es una organización que define estándares de la industria para formatos de contenedores y runtimes, y Docker utiliza runc, que cumple con estos estándares, para gestionar contenedores.

Cuando ocurre este error, puede experimentar los siguientes síntomas:

  • Los contenedores no inician con el comando docker run
  • Los servicios no se inician con docker-compose up
  • Los registros del contenedor muestran el mensaje “OCI runtime create failed”
  • Aparecen mensajes de error como “runc create failed: unable to start container process”

El formato del mensaje de error típicamente se ve así:

Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "python": executable file not found in $PATH: unknown

Este error puede ocurrir en cualquier entorno Docker, incluyendo entornos de desarrollo, pipelines de CI/CD y entornos de producción, afectando significativamente el desarrollo e implementación de aplicaciones basadas en contenedores.

Causas de este error

Hay múltiples causas potenciales para el error OCI runtime create failed. La clave está en la parte después de “caused:” en el mensaje de error, por lo que es importante verificar el mensaje de error completo primero.

Causa 1: Ejecutable no encontrado

Una de las causas más comunes es que el ejecutable o comando especificado no existe dentro del contenedor. Este error ocurre cuando el comando especificado en ENTRYPOINT o CMD del Dockerfile no existe en la imagen del contenedor.

Por ejemplo, si intenta ejecutar el comando python en una imagen base que no tiene Python instalado, verá el siguiente error:

exec: "python": executable file not found in $PATH

Esto ocurre frecuentemente cuando se utilizan imágenes ligeras como Alpine Linux.

Causa 2: Control de acceso SELinux/AppArmor

Este error también puede ocurrir cuando módulos de seguridad como SELinux (Security-Enhanced Linux) o AppArmor bloquean procesos del contenedor u operaciones de montaje. Esto es particularmente problemático en las siguientes situaciones:

  • Al montar directorios del host como volúmenes
  • Al acceder a archivos de dispositivo específicos
  • Al ejecutar contenedores que requieren operaciones privilegiadas

En entornos con SELinux habilitado, puede ver mensajes de error como:

write /proc/self/attr/keycreate: permission denied

Causa 3: Problemas con el script de entrada

Los errores también pueden ocurrir cuando hay problemas con archivos de script como entrypoint.sh especificados en el Dockerfile. Las causas principales incluyen:

  • Archivo no copiado a la imagen
  • Ruta de archivo incorrecta
  • Permiso de ejecución no otorgado
  • Finales de línea (CRLF) de scripts creados en Windows no reconocidos en Linux

Causa 4: Problemas de versión de Docker o runc

Este error puede ocurrir cuando las versiones de Docker o runc son incompatibles con el kernel del SO host. Los problemas se han reportado particularmente después de actualizaciones en Proxmox VE y otros entornos de virtualización. Muchos casos se resuelven actualizando a Docker 25 o superior.

Causa 5: Problemas de configuración de cgroup

Los errores también ocurren cuando la configuración de cgroup (Control Groups) del contenedor es incompatible con el sistema host. Este problema se reporta frecuentemente, especialmente durante el período de transición de cgroupsv1 a cgroupsv2.

Solución 1: Verificar ejecutables y rutas (Recomendado)

La solución más efectiva para probar primero es verificar los ejecutables y rutas dentro del contenedor.

Paso 1: Verificar el contenido de la imagen

Primero, verifique que los comandos necesarios existan en la imagen problemática:

# Verificar el sistema de archivos en la imagen
docker run --rm --entrypoint ls myapp:latest /usr/bin/

# Verificar si existe un comando específico
docker run --rm --entrypoint which myapp:latest python

Paso 2: Modificar el Dockerfile

Si el ejecutable no existe, modifique el Dockerfile para instalar los paquetes necesarios:

# Para Alpine Linux
FROM alpine:latest
RUN apk add --no-cache python3 py3-pip

# Para Debian/Ubuntu
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3 python3-pip

Paso 3: Verificar ENTRYPOINT y CMD

Verifique que ENTRYPOINT y CMD estén correctamente configurados en el Dockerfile:

# Ejemplo correcto
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["python3", "app.py"]

# Se recomienda usar rutas absolutas
ENTRYPOINT ["/usr/local/bin/python3"]

Notas importantes

  • Al usar scripts de shell, siempre otorgue permisos de ejecución: RUN chmod +x /app/entrypoint.sh
  • Para scripts creados en Windows, convierta los finales de línea usando el comando dos2unix o maneje esto dentro del Dockerfile

Solución 2: Abordar problemas de SELinux/AppArmor

Aquí está cómo abordar errores causados por SELinux o AppArmor.

Verificar el estado de SELinux

# Verificar estado de SELinux
sestatus

# Verificar registros recientes de denegación de SELinux
ausearch -m avc -ts recent

Configuración de etiquetas para montajes de volumen

Al montar volúmenes en entornos SELinux, establezca las etiquetas apropiadas:

# Opción :z (para volúmenes compartidos)
docker run -v /host/path:/container/path:z myapp:latest

# Opción :Z (para volúmenes privados)
docker run -v /host/path:/container/path:Z myapp:latest

Configuración de etiquetas persistentes

Para directorios de uso frecuente, puede establecer etiquetas SELinux persistentes:

# Establecer contexto SELinux para contenedores
chcon -Rt svirt_sandbox_file_t /path/to/volume

Deshabilitar etiquetas SELinux para pruebas

Para propósitos de solución de problemas, puede deshabilitar temporalmente las etiquetas SELinux:

docker run --security-opt label=disable myapp:latest

Importante: No se recomienda deshabilitar permanentemente SELinux en entornos de producción. Configure políticas apropiadas después de comprender completamente los riesgos de seguridad.

Solución 3: Actualización de Docker/runc y cambios de configuración (Avanzado)

Soluciones para problemas de versión o cuando se necesita configuración avanzada.

Actualizar Docker

Si está usando una versión antigua de Docker, actualice a la última versión:

# Para Ubuntu/Debian
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Para CentOS/RHEL
sudo yum update docker-ce docker-ce-cli containerd.io

Verificar y actualizar la versión de runc

# Verificar versión de runc
runc --version

# Actualizar runc por separado si es necesario
sudo apt-get install runc

Modificar la configuración de systemd

En algunos entornos, puede necesitar modificar la configuración de systemd de Docker:

# Editar archivo de servicio de Docker
sudo systemctl edit docker.service

# Agregar la siguiente configuración (resuelve problemas de MountFlags)
[Service]
MountFlags=shared

# Aplicar cambios
sudo systemctl daemon-reload
sudo systemctl restart docker

Configurar el controlador de cgroup

Si hay problemas de compatibilidad del controlador de cgroup, modifique la configuración del daemon de Docker:

# Editar /etc/docker/daemon.json
sudo nano /etc/docker/daemon.json

Agregue el siguiente contenido:

{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}

Después de la configuración, reinicie Docker:

sudo systemctl restart docker

Cómo prevenir este error

Estas son las mejores prácticas para prevenir errores de OCI runtime create failed.

Mejores prácticas de Dockerfile

  1. Use imágenes base confiables: Use imágenes oficiales o verificadas y asegúrese de que contengan las dependencias necesarias.

  2. Utilice construcciones de múltiples etapas: Evite incluir herramientas o archivos innecesarios en la imagen final.

  3. Establezca explícitamente permisos de ejecución: Siempre ejecute chmod +x en archivos de script.

  4. Use rutas absolutas: Use rutas absolutas en lugar de relativas en ENTRYPOINT y CMD.

Mantenimiento regular

  1. Mantenga Docker y runc actualizados: Realice actualizaciones regulares para parches de seguridad y mejoras de compatibilidad.

  2. Elimine imágenes y contenedores no utilizados: Ejecute docker system prune regularmente para liberar espacio en disco.

  3. Monitoree los registros: Verifique regularmente los registros del sistema Docker con journalctl -u docker.

Pruebas previas a la implementación

Siempre verifique que los contenedores se inicien correctamente en entornos locales o de staging antes de implementar en producción. También es efectivo incorporar pruebas de inicio de contenedores en su pipeline de CI/CD.

Resumen

El error “OCI runtime create failed” de Docker es un error común que indica que el runtime del contenedor no pudo iniciar el contenedor. Las causas principales incluyen ejecutables faltantes, control de acceso SELinux/AppArmor, errores de configuración de entrypoint, problemas de versión de Docker/runc e inconsistencias en la configuración de cgroup.

Al solucionar problemas, es importante verificar primero la parte después de “caused:” en el mensaje de error para identificar la causa específica. En muchos casos, el problema puede resolverse modificando el Dockerfile o agregando opciones de montaje de volumen.

Si el problema persiste, intente los siguientes pasos:

  1. Verifique información de error más detallada con docker logs o journalctl
  2. Busque problemas similares en los foros oficiales de Docker o Stack Overflow
  3. Considere actualizar su versión de Docker
  4. Verifique la compatibilidad entre el kernel del SO host y Docker

La tecnología de contenedores evoluciona diariamente, y muchos problemas se resuelven en versiones más nuevas. Mantenga un entorno de contenedores estable mediante actualizaciones regulares y una gestión de configuración adecuada.

Referencias

コメント

タイトルとURLをコピーしました