¿Cómo investigar un proceso principal que ha muerto en un contenedor acoplable?

A veces hay que investigar un contenedor, que se detiene, o un contenedor que después de arrancar muere muy rápido y se detiene.

docker exec -ti <id> bash solo funciona en contenedores en ejecución, una vez que finaliza, el indicador de bash también finaliza.

Con docker startusted no puede proporcionar un comando diferente, y si el contenedor vuelve a morir abruptamente, no tendrá tiempo suficiente para entrar en el contenedor e investigar.

Podemos hacerlo docker commit, luego docker runen la nueva imagen con un comando diferente, pero me pregunto si hay otras alternativas.

Nota : docker logssolo devuelve las aplicaciones impresas en stdout / stderr. Eso podría no ser suficiente para descubrir cuál era el problema.

docker containers post-mortem

— SztupY
fuente

Después de un tiempo pensando en ello: ¿el proceso principal de Docker? Como un contenedor tiene como objetivo ejecutar solo un proceso, o bien se debe eliminar el término 'principal', o está haciendo algo extraño (como ejecutar un proceso de inicio), o está tomando hilos como procesos ... Supongo que es opción uno, pero tuve que decirlo porque me molesta

— Tensibai

@Tensibai a veces tienes que ejecutar algo como dumb-init, para manejar el problema pid 1 / señalización en contenedores, si tu comando principal no puede manejarlo por sí mismo. También puede haber otros casos en los que un contenedor acoplable ejecuta más de un proceso

— SztupY

Sí, eso es lo que yo llamo extraño, principalmente porque se han hecho contenedores para aislar un proceso. A veces, los contenedores no son la solución para una aplicación y el deseo de poner todo dentro de un contenedor es más un camino hacia los dolores de cabeza que cualquier otra cosa.

— Tensibai

Respuestas:

Las formas generales de rastrear por qué falló un proceso en Linux son buenas. Una de estas formas es ejecutar un proceso straceque le dirá qué hizo el proceso de llamadas del sistema y, por lo general, le indicará el motivo de la falla.

Puede crear una Dockerfileque se vea así:

FROM original_image

RUN apt-get -y update && apt-get install -y strace

# build with `docker build -t debug_version`

Luego ejecuta tu nueva imagen usando docker run debug_version strace original_cmd.

Para los procesos que bifurcan a los hijos (y luego mueren) que desea ejecutar stracecon la -ffopción. También puede asignar algún archivo utilizando los volúmenes de datos de Docker y usar la -oopción de stracepara escribir en él. Pero en general stracedejará la salida en stdout, que se puede leer usando docker log.

P relacionada : el proceso de Linux termina misteriosamente

— Evgeny
fuente

Este medio de que todavía tengo a docker commitmi contenedor detenido primero en tener una imagen a partir de

— SztupY

Dijiste que muere al comienzo. Asumo que tienes una imagen entonces. Para aquellos que están detenidos, sí, se requiere una confirmación.

— Evgeny

Ese es solo uno de los escenarios para obtener un contenedor detenido

— SztupY

También hay un paquete para straceAlpine Linux, pkgs.alpinelinux.org/package/edge/main/x86_64/strace . Utilice el gestor de paquetes Alpine para instalarlo, apk install strace.

— Evgeny

Hasta donde yo sé, commity runson las mejores opciones aquí para darle acceso completo al contenedor como estaba cuando murió.

Idealmente, su contenedor escupiría información más útil cuando falla, pero ese es otro tema completamente diferente.

Editar: para expandir mi respuesta, si el contenedor se está muriendo en el inicio, también puede usar docker runpara especificar una alternativa --entrypointy CMD. En general, configuraré esto en un bucle o algo que no salga solo. Una vez que esté en el contenedor, puede ejecutar manualmente los pasos que están fallando y luego inspeccionar el resultado sin tener que preocuparse por la salida del contenedor.

— gusano
fuente