Why does "docker attach" hang?

Question

I can run an ubuntu container successfully:

# 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

But executing docker attach hangs:

# docker attach 3aef6e642327

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

Why does docker attach hang?

Update:

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

prerequisite:

"docker attach" reuse the same tty, not open new tty.

(1) Executing the docker run without daemon mode:

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

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) Run docker run in daemon mode:

# docker run -it -d ubuntu
91262536f7c9a3060641448120bda7af5ca812b0beb8f3c9fe72811a61db07fc

Actually, the following should have been outputted to stdout from the running container:

root@91262536f7c9:/#

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

Answer 1

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.

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 

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.

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).

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:

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

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?

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.

• Taken from a comment on this github issue. You can find more insight in the comments of this issue.

Answer 2

Using: docker exec -it CONTAINER_ID/NAME bash

Instead: docker attach...

Answer 3

I just had a similar problem today and was able to fix it:

Here is what was happening for me:

docker-compose logs -f nginx
Attaching to laradock_nginx_1

Then it would hang there until I quit via CTRL-C: ^CERROR: Aborting.

docker ps -a showed that what SHOULD have been called laradock_nginx did not exist with that Image Name, so I figured I'd just remove and re "up" that container:

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

Unfortunately: ERROR: No such service: laradock_nginx

So I did a sudo reboot and then docker ps -a, but laradock_nginx still wasn't there.

Luckily, docker-compose up -d nginx then worked and docker-compose logs -f nginx now works.

Answer 4

When I run docker attach container-name, then nothing output, even Ctrl-c is invalid. So, first try

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

and then ctrl-c can stop it. Why it didn't output anything? just because the container doesn't output. Actually I need to enter my container and run some shell command. So the correct command is

docker exec -ti container-name bash

Answer 5

I ran into this issue as well when attempting to attach to a container that was developed by someone else and already running a daemon. (In this case, it was LinuxServer's transmission docker image).

Problem:

What happened was the terminal appeared to 'hang', where typing anything didn't help and wouldn't show up. Only Ctrl-C would kick me back out.

docker run, docker start, docker attach all was not successful, turns out the command I needed (after the container has been started with run or start) was to execute bash, as chances are the container you pulled from doesn't have bash already running.

Solution:

docker exec -it <container-id> bash

(you can find the container-id from running docker ps -a).

This will pull you into the instance with a functional bash as root (assuming there was no other explicit set up done by the image you pulled).

I know the accepted answer has captured this as well, but decided to post another one that is a little more terse and obvious, as the solution didn't pop out for me when I was reading it.

Answer 6

If you cannot access command line, just make sure you run your container with -i flag at start.

Answer 7

This happened to me once for the following reason:

It could be that the bash command inside the container is executing a "cat" command.

So when you attach to the container (the bash command) you are actualy inside the cat command which is expecting input. (text and/or ctrl-d to write the file)