linux - ¿Por qué se cuelga "docker attach"?

hang (6)

Puedo ejecutar un contenedor ubuntu éxito:

# docker run -it -d ubuntu 3aef6e642327ce7d19c7381eb145f3ad10291f1f2393af16a6327ee78d7c60bb # docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3aef6e642327 ubuntu "/bin/bash" 3 seconds ago Up 2 seconds condescending_sammet

Pero la ejecución de docker attach bloquea:

# docker attach 3aef6e642327

Hasta que presione cualquier tecla, como Enter :

# docker attach 3aef6e642327 root@3aef6e642327:/# root@3aef6e642327:/# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

¿Por qué se cuelga docker attach ?

Actualización :

Después de leer los comentarios, creo que obtengo las respuestas:

requisito previo:

"docker attach" reutiliza el mismo tty, no abre el nuevo tty.

(1) Ejecutar la ejecución de docker run sin modo demonio:

# docker run -it ubuntu root@eb3c9d86d7a2:/#

Todo está bien, luego ejecuta el comando ls :

root@eb3c9d86d7a2:/# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var root@eb3c9d86d7a2:/#

(2) Ejecute docker run Run en modo demonio:

# docker run -it -d ubuntu 91262536f7c9a3060641448120bda7af5ca812b0beb8f3c9fe72811a61db07fc

En realidad, lo siguiente debería haberse enviado a stdout desde el contenedor en ejecución:

root@91262536f7c9:/#

Por lo tanto, la ejecución de docker attach parece bloquearse, pero en realidad está esperando su entrada:

# docker attach 91262536f7c9 ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var root@91262536f7c9:/#

Hoy tuve un problema similar y pude solucionarlo:

Esto es lo que me estaba pasando:

docker-compose logs -f nginx Attaching to laradock_nginx_1

Luego quedaría allí hasta que salga por CTRL-C: ^CERROR: Aborting.

docker ps -a mostró que lo que DEBERÍA haberse llamado laradock_nginx no existía con ese Nombre de imagen, así que pensé que simplemente quitaría y volvería a "cargar" ese contenedor:

docker stop cce0c32f7556 docker rm cce0c32f7556 docker-compose up -d laradock_nginx

Desafortunadamente: ERROR: No such service: laradock_nginx

Así que hice un sudo reboot y luego docker ps -a , pero laradock_nginx todavía no estaba allí.

Afortunadamente, docker-compose up -d nginx funcionó y docker-compose logs -f nginx ahora funcionan.

Cuando ejecuto docker attach container-name , entonces no sale nada, incluso Ctrl-c no es válido. Entonces, primero intenta

docker attach container-name --sig-proxy=false

y luego ctrl-c puede detenerlo. ¿Por qué no produjo nada? solo porque el contenedor no sale. En realidad, necesito ingresar a mi contenedor y ejecutar algún comando de shell. Entonces el comando correcto es

docker exec -ti container-name bash

Esto me sucedió una vez por la siguiente razón:

Podría ser que el comando bash dentro del contenedor esté ejecutando un comando "cat".

Entonces, cuando se conecta al contenedor (el comando bash), se encuentra realmente dentro del comando cat, que espera una entrada. (texto y / o ctrl-d para escribir el archivo)

Realmente no cuelga . Como puede ver en el comentario a continuación (está ejecutando " /bin/bash " como comando) parece ser un comportamiento esperado al adjuntar.

Según tengo entendido, se conecta al shell de ejecución y solo el stdin / stdout / stderr, dependiendo de las opciones que pase junto con el comando de ejecución, solo le mostrará lo que entra / sale desde ese momento . (Alguien con un poco más de conocimiento profundo con suerte puede explicar esto en un nivel superior).

Como escribí en mi comentario sobre su pregunta, hay varias personas que han abierto un problema en el repositorio de Docker Github que describe un comportamiento similar:

Como mencionas shell, supongo que ya tienes un shell en ejecución. adjuntar no inicia un nuevo proceso, entonces, ¿cuál es el comportamiento esperado de conectarse a las secuencias de entrada / salida / error de un proceso en ejecución? No pensé en esto. Por supuesto, este es el comportamiento esperado de adjuntar a un shell en ejecución, pero ¿es deseable?

¿Sería posible enjuagar stdout / stderr en la base acoplable, lo que obligaría a imprimir el indicador de shell o es un poco más complejo que eso? Eso es lo que personalmente "esperaría" al conectarme a un shell que ya se está ejecutando.

Si es necesario, puede cerrar este problema, solo sentí la necesidad de documentar esto y obtener algunos comentarios.

Tomado de un comment sobre este tema de github . Puede encontrar más información en los comentarios de este tema.

Si, en lugar de enter , comenzaría a escribir un comando, no vería la línea de aviso vacía adicional . Si tuvieras que correr

$ docker exec -it ubuntu <container-ID-or-name> bash

donde <container-ID-or-name> es el ID o el nombre del contenedor después de ejecutar docker run -it -d ubuntu (por lo tanto, 3aef6e642327 o condescending_sammet en su pregunta) ejecutaría un nuevo comando, por lo que no tendría este "stdout problema "de adjuntar a uno existente.

Ejemplo

Si tuviera un Dockerfile en un directorio que contiene:

FROM ubuntu:latest ADD ./script.sh /timescript.sh RUN chmod +x /timescript.sh CMD ["/timescript.sh"]

Y tenga un script bash simple script.sh en el mismo directorio que contiene:

#!/bin/bash #trap ctrl-c and exit, couldn''t get out #of the docker container once attached trap ctrl_c INT function ctrl_c() { exit } while true; do time=$(date +%N) echo $time; sleep 1; done

Luego compile (en este ejemplo en el mismo directorio que Dockerfile y script.sh) y ejecútelo con

$ docker build -t nan-xiao/time-test . ..stuff happening... $ docker run -itd --name time-test nan-xiao/time-test

Finalmente attach

$ docker attach time-test

Terminará conectado a un contenedor imprimiendo la hora cada segundo. (CTRL-C para salir)

Ejemplo 2

O si tuviera un Dockerfile contiene, por ejemplo, lo siguiente:

FROM ubuntu:latest RUN apt-get -y install irssi ENTRYPOINT ["irssi"]

Luego ejecute en el mismo directorio:

$ docker build -t nan-xiao/irssi-test .

Luego ejecútalo:

$ docker run -itd --name irssi-test nan-xiao/irssi-test

Y finalmente

$ docker attach irssi-test

Terminaría en una ventana irssi en ejecución sin este comportamiento particular. Por supuesto, puede sustituir irrsi por otro programa.

Si no puede acceder a la línea de comandos, solo asegúrese de ejecutar su contenedor con el indicador -i al inicio.

También me encontré con este problema al intentar conectar un contenedor que fue desarrollado por otra persona y que ya ejecutaba un demonio. (En este caso, era la imagen del acoplador de transmission de LinuxServer).

Problema:

Lo que sucedió fue que la terminal parecía "colgarse", donde escribir cualquier cosa no ayudaba y no aparecía. Solo Ctrl-C me echaría de nuevo.

docker run , docker start , docker attach all no tuvo éxito, resulta que el comando que necesitaba (después de que el contenedor se haya iniciado con run o start ) era ejecutar bash , ya que es probable que el contenedor del que sacó no tenga bash corriendo.

Solución:

docker exec -it <container-id> bash

(puede encontrar el container-id de container-id ejecutando docker ps -a ).

Esto lo llevará a la instancia con un bash funcional como root (suponiendo que no haya otra configuración explícita realizada por la imagen que extrajo).

Sé que la respuesta aceptada también ha capturado esto, pero decidí publicar otra que es un poco más concisa y obvia, ya que la solución no se me ocurrió cuando la estaba leyendo.