Tuve un problema con un contenedor, a pesar de que se construye perfectamente, no se inicia correctamente. La causa es una solución alternativa que he agregado al Dockerfile (para tener un enrutamiento /etc/hosts autoconfigurado)
Obviamente, hay algún error allí, pero me pregunto cómo puedo obtener más información sobre lo que está haciendo Docker mientras se ejecuta. por ejemplo, esto funciona:
$ docker run image lsusr bin ...
Pero esto no:
$ docker run image ls -l$
No hay nada en los registros y tampoco puedo llamar a un shell interactivo. Puedo usar strace para ver lo que está sucediendo, pero esperaba que hubiera una mejor manera.
¿Hay alguna forma de que pueda configurar Docker para que sea más detallado?
EDITAR: Gracias a Andrew D. Ahora sé lo que está mal con el código anterior (lo dejé para que se pueda entender su respuesta). Ahora el problema sigue siendo cómo podría depurar algo como esto o entender por qué ls-l falló por qué ls no.
EDITAR:- D=true podría dar más salida, aunque no en mi caso...
Ventana acoplable events el comando puede ayudar y Registros de Docker el comando puede recuperar registros incluso después de que la imagen no se haya iniciado.
Primer comienzo docker events en el fondo para ver qué está pasando.
docker events&
A continuación, ejecute su aplicación docker run ... comando. Entonces debería ver algo como lo siguiente en la pantalla:
2015-12-22T15:13:05.503402713+02:00 xxxxxxxacd8ca86df9eac5fd5466884c0b42a06293ccff0b5101b5987f5da07d: (from xxx/xxx:latest) die
A continuación, puede obtener el ID hexadecimal de inicio del mensaje anterior o la salida del comando ejecutar. Luego puede usarlo con el comando logs:
docker logs <copy the instance id from docker events messages on screen>
Ahora debería ver algunos resultados del inicio fallido de la imagen.
Como @alexkb sugirió en un comentario: docker events& puede ser problemático si su contenedor se reinicia constantemente desde algo como el servicio AWS ECS. En este escenario, puede ser más fácil obtener el ID hexadecimal del contenedor de los registros en /var/log/ecs/ecs-agent.log.<DATE>. Luego usa Docker logs <hex id>.
Bueno, lo mejor que he descubierto hasta ahora es:
#stop the current demon and start it in debug modussudo service docker stopdockerd -D # --debug
Simplemente inicie el cliente desde un nuevo shell. La idea errónea era pensar que el cliente realmente hace cualquier cosa... bueno, solo se está comunicando con el demonio, así que no quieres depurar el cliente, pero el daemon en sí (normalmente).
En mi caso, el -a (adjuntar a STDOUT/STDERR) la bandera fue suficiente:
user@machine:~$ docker start -a server_nameError: The directory named as part of the path /log/log_path/app.log does not exist.For help, use /usr/bin/supervisord -h
Mostró el error de inicio (en nuestro caso, una ruta de registro faltante utilizada por supervisord). Supongo que la mayoría de los errores de inicio de contenedores también se mostrarían aquí.
No puedo responder a su pregunta sobre cómo hacer que la salida de docker sea más completa, pero puedo decirle que la sustitución de expresiones regulares en el lugar de una cadena en un archivo .so es un poco loca: la cadena solo tiene tanto espacio asignado, y si cambia las compensaciones de archivo de otras entradas, el archivo elf se corrompe. Intente ejecutar objdump o readelf en su archivo. so después de ejecutar el comando perl (antes del cambio de LD_LIBRARY_PATH) fuera de un contenedor dollars dollars to donuts ahora está corrupto.
La razón por la que funciona en este truco tristemente necesario esto se debe a que "tmp" y "etc" tienen la misma longitud de cadena, por lo que no cambian las compensaciones. Considere el directorio /dkr o similar si prefiere no usar /tmp.
Si debe adoptar este enfoque y las rutas deseadas no se pueden cambiar, reconstruya la biblioteca y cambie la ruta predeterminada para /etc/hosts en la fuente. O mejor, al construir su modificado libnss_files.so cámbiele el nombre a algo como libnss_altfiles.so y cambio nsswitch.conf utilizar hosts: altfiles al iniciar su contenedor docker (a menos que docker tenga nsswitch montado en bind.conf, entonces no puedes cambiarlo). Esto le permitirá tener la libnss_altfiles.so en paralelo con sus bibliotecas normales en el sistema base. Si docker enlaza, monte nsswitch.conf, deje una copia de su reconstruido libnss_files.so en su directorio /lib-override listo para ser cargado por LD_LIBRARY_PATH.
Como advertencia, los binarios suid/sgid ignoran LD_LIBRARY_PATH y LD_PRELOAD, por lo que algunas cosas se romperán (léase: vuelva a usar el /etc/hosts predeterminado) si usa esas variables.