为什么"dockerattach"悬挂? [英] Why does "docker attach" hang?

问题描述

我可以成功运行ubuntu容器:

# 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

但是执行docker attach会挂起:

# docker attach 3aef6e642327

在我按任意键之前，例如Enter:

Until I press any key, such as 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

为什么docker attach挂起?

更新:

阅读评论后，我认为我得到了答案:

After reading the comments, I think I get the answers:

先决条件:

"docker attach"重复使用相同的tty，而不打开新的tty.

(1)在没有守护程序模式的情况下执行docker run:

(1) Executing the docker run without daemon mode:

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

一切正常，然后运行ls命令:

Everything is OK, then run ls command:

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)在守护程序模式下运行docker run:

(2) Run docker run in daemon mode:

# docker run -it -d ubuntu
91262536f7c9a3060641448120bda7af5ca812b0beb8f3c9fe72811a61db07fc

实际上，以下内容应该已经从正在运行的容器中输出到stdout:

root@91262536f7c9:/#

因此执行docker attach似乎挂起，但实际上它正在等待您的输入:

So executing docker attach seems to hang, but actually it is waiting for your input:

# 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:/#

推荐答案

它不是真正的 hang .如您在下面的注释中看到的(您正在以命令方式运行"/bin/bash")，似乎在连接时出现了预期的行为.

It does not really hang. As you can see in the comment below (You are running "/bin/bash" as command) it seems to be expected behaviour when attaching.

据我了解，您附加到正在运行的shell上，而只是stdin/stdout/stderr(取决于与run命令一起传递的选项)将仅向您显示进出的任何内容 从那一刻起 . (希望您有更深入的知识的人可以在更高层次上对此进行解释).

As far as I understand you attach to the running shell and just the stdin/stdout/stderr - depending on the options you pass along with the run command - will just show you whatever goes in/out from that moment. (Someone with a bit more in-depth knowledge hopefuly can explain this on a higher level).

正如我在对您的问题的评论中所写的那样，有些人在docker github存储库上打开了一个描述类似行为的问题:

As I wrote in my comment on your question, there are several people who have opened an issue on the docker github repo describing similar behaviour:

• 泊坞窗附件[容器]挂起，需要输入#8521
• docker attach在连接到容器时会挂起设置终端状态

• docker attach [container] hangs, requires input #8521
• docker attach hangs setting terminal state when attaching to container

由于您提到了外壳程序，因此我假设您已经有一个外壳程序正在运行. attach不会启动新进程，因此连接到正在运行的进程的in/​​ out/err流的预期行为是什么? 我没有考虑这个.当然，这是连接到运行中的shell的预期行为，但这是合乎需要的吗?

Since you mention shell, I assume you have a shell already running. attach doesn't start a new process, so what is the expected behavior of connecting to the in/out/err streams of a running process? I didn't think about this. Of course this is the expected behavior of attaching to a running shell, but is it desirable?

是否有可能在docker Attach上刷新stdout/stderr从而强制打印shell提示，或者比这更复杂?这就是我个人在连接到已经运行的shell时会期待"的情况.

Would it be at all possible to flush stdout/stderr on docker attach thereby forcing the shell prompt to be printed or is it a bit more complex than that? That's what I personally would "expect" when attaching to an already running shell.

如有必要，请随时关闭此问题，我只是觉得有必要对此进行记录并获得一些反馈.

Feel free to close this issue if necessary, I just felt the need to document this and get some feedback.

• 从评论中获取://github.com/docker/docker/issues/8521"rel =" noreferrer> github问题.您可以在此问题的评论中找到更多见识.
• Taken from a comment on this github issue. You can find more insight in the comments of this issue.

如果您要代替键入enter而开始输入命令，则不会看到 extra 空的提示行.如果你要跑步

If instead of enter you would start typing a command, you would not see the extra empty prompt line. If you were to run

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

其中，<container-ID-or-name>是运行docker run -it -d ubuntu后容器的ID或名称(因此，问题中为3aef6e642327或condescending_sammet)，它将运行 new 命令，因此没有此"stdout问题"，即附加到现有的问题上.

where <container-ID-or-name> is the ID or name of the container after you run docker run -it -d ubuntu (so 3aef6e642327 or condescending_sammet in your question) it would run a new command, thus not having this "stdout problem" of attaching to an existing one.

如果在包含以下内容的目录中有Dockerfile:

If you would have a Dockerfile in a directory containing:

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

在同一个目录中有一个简单的bash脚本script.sh，其中包含:

And have a simple bash script script.sh in the same directory containing:

#!/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

然后构建(在此示例中，与Dockerfile和script.sh位于同一目录中)并使用

Then build (in this example in the same directory as the Dockerfile and script.sh) and run it with

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

最后attach

$ docker attach time-test

您最终将附着在一个容器上，并每秒打印一次时间. (CTRL-C退出)

You will end up attached to a container printing out the time every second. (CTRL-C to get out)

或者如果您的Dockerfile包含以下内容:

Or if you would have a Dockerfile containing for example the following:

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

然后在同一目录中运行:

Then run in the same directory:

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

然后运行它:

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

最后

$ docker attach irssi-test

您最终将在没有任何特定行为的情况下在运行的irssi窗口中使用.当然，您可以用irrsi代替另一个程序.

You would end up in a running irssi window without this particular behaviour. Of course you can substitute irrsi for another program.

这篇关于为什么"dockerattach"悬挂?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！