docker-compose up hangs when tty parameter is true

[rgorodischer]

Here's a minimal setup to reproduce the issue:

Dockerfile content:

FROM debian:jessie

CMD ["/bin/bash"]

docker-compose.yml content:

test-system:
  build: .
  stdin_open: true
  tty: true

Here's what happens when I try docker-compose up:

$ docker-compose up test-system
Creating testcompose_test-system_1
Attaching to testcompose_test-system_1
ERROR: Couldn't connect to Docker daemon at http+docker://localunixsocket - is it running?

If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.

My user is added to docker group, and the output is the same when run from sudo.

It manages to attach only with docker-compose run command.
I tried the experiment with same outcomes on Docker version 1.9.1, build a34a1d5, and compose versions 1.4.0, 1.6.0, and 1.6.2.

UPD:
docker info output:

$ docker info
Containers: 2
Images: 152
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 156
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-29-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 8
Total Memory: 11.62 GiB
Name: romang-HP
ID: GDTJ:MBV5:DD5J:3IO2:T4K4:6A4P:QMXM:PLER:TIQA:2MIH:UZ52:VVDE
WARNING: No swap limit support

docker-compose --verpose up output:

$ docker-compose --verbose up test-system
compose.config.config.find: Using configuration files: ./docker-compose.yml
docker.auth.auth.load_config: File doesn't exist
compose.cli.command.get_client: docker-compose version 1.6.0, build d99cad6
docker-py version: 1.7.0
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=3.13.0-29-generic, Os=linux, BuildTime=Fri Nov 20 13:12:04 UTC 2015, ApiVersion=1.21, Version=1.9.1, GitCommit=a34a1d5, Arch=amd64, GoVersion=go1.4.2
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=testcompose', u'com.docker.compose.service=test-system', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 1 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- (u'15cbcae7bf798470b019b4cd4474bb04a353d3b6338a321916b3c42d066b0917')
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> {u'AppArmorProfile': u'',
 u'Args': [],
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/bash'],
             u'Domainname': u'',
             u'Entrypoint': None,
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'],
             u'Hostname': u'15cbcae7bf79',
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=testcompose', u'com.docker.compose.service=test-system', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 1 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- (u'testcompose_test-system')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/bash'],
             u'Domainname': u'',
             u'Entrypoint': None,
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'],
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- (u'15cbcae7bf798470b019b4cd4474bb04a353d3b6338a321916b3c42d066b0917')
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> {u'AppArmorProfile': u'',
 u'Args': [],
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/bash'],
             u'Domainname': u'',
             u'Entrypoint': None,
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'],
             u'Hostname': u'15cbcae7bf79',
...
compose.service.execute_convergence_plan: testcompose_test-system_1 is up-to-date
Attaching to testcompose_test-system_1
compose.cli.verbose_proxy.proxy_callable: docker attach <- (u'15cbcae7bf798470b019b4cd4474bb04a353d3b6338a321916b3c42d066b0917', stderr=True, logs=True, stream=True, stdout=True)
compose.cli.verbose_proxy.proxy_callable: docker attach -> <generator object _stream_raw_result at 0x7f10446e9780>
docker.auth.auth.load_config: File doesn't exist
ERROR: compose.cli.main.main: Couldn't connect to Docker daemon at http+docker://localunixsocket - is it running?

If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.

[dnephin]

From the title it sounds like this works for you if you remove the tty: true from the Compose file, is that correct?

Please include the output of docker info, and docker-compose --verbose up. What environment are you running on (linux host, docker-machine vm or cloud instance) ?

[rgorodischer]

Updated.

It works without tty: true, but I want to use the container to make some development with build tool which supports interactive mode. That's why I'd like to have interactive mode when running docker-compose up.

[immarvin]

ran into the same issue

[root@c910f05c01bc07 xcat-docker]# docker version
Client:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 16:16:33 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 16:16:33 2016
 OS/Arch:      linux/amd64


[root@c910f05c01bc07 xcat-docker]# docker-compose version
docker-compose version 1.7.0dev, build 99d68be
docker-py version: 1.8.0-dev
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013

[dnephin]

So the important information I was missing is that it sits and waits for a timeout to happen. This error happens after 60 seconds, not right away, correct?

This is because we have a timeout, and after some period of no activity, you hit the timeout and it disconnects. There is some good discussion here: #2338 (comment)

We need to look at either removing the timeout, or set TCP keep-alive (or possibly both).
Another problem is that we don't seem to be getting the right connection error message from this. It should say that it's a timeout.

[dnephin]

On master I'm seeing a clear socket.timeout for this exception now. I'm not sure what changed it, but at least that error is more clear about the failure.

[dnephin]

It turns out that non-tty mode already disables the timeout indocker-py. See docker/docker-py#630 and docker/docker-py@70b921f

[igorpejic]

I did this instead of tty: true:

command: sleep 5d  # sleep for 5 days

and then: docker exec -it name_of_your_continaer /bin/bash

[greg0ire]

@igorpejic : a bit ugly, but hey, it seems to work!

[mrkongo]

@igorpejic, instead if I want to use tty: true in docker-compose.yml file because I need to use docker attach name_container_web_1 for development tools what to do?

I'm in the 60sec timeout problem right now.

[igorpejic]

@mrkongo What hinders you from using my solution?

[zacblazic]

We are currently Dockerizing our app for local development and as you can imagine, debugging forms a key part of the experience.

Using something like docker-compose run app bundle exec rails console works just fine because the run command opens up a TTY by default.

On the other hand, if you want to attach to a process you need to set tty and stdin_open to true.
While tty: true is not critical to be able to interact with the debugger, it is needed to be able to detach (ctrl + p, ctrl + q) from the container. Without it you can only exit the container with (ctrl + c).

Unfortunately, setting tty: true in the compose file is a major issue as it stops you from tailing logs for more than 60 seconds if the log is quiet:

$ docker-compose --verbose logs -f app
compose.config.config.find: Using configuration files: ./docker-compose.yml
...
...
...
ERROR: compose.cli.errors.log_timeout_error: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

$ docker -v
Docker version 1.12.2-rc1, build 45bed2c, experimental
$ docker-compose -v
docker-compose version 1.8.1, build 878cff1

What are options?

[ernestoalejo]

Until this bug gets fixed you can set a big timeout to avoid the error:

COMPOSE_HTTP_TIMEOUT=60000 docker-compose --verbose logs -f app

[ghost]

@shin- I tried just now with docker-compose 1.16.1 on Windows (downloaded from Github). Nothing. byebug or other I can use from docker attach doesn't work with simple docker-compose up. I'm using

      stdin_open: true
      tty: true

on my app service.

[wyqydsyq]

I am also in a similar scenario to @synthecypher. I have a script I want to run in my docker container with coloured output (meaning I need to specify tty: true) but when using this option, the TTY does not get detached after the script ends.

The container does exit as expected when my script finishes, it's just that my host terminal remains attached to the container's TTY. I've attached screenshots showing this.

My script has finished and is of State: Exit 0 but the TTY is still attached

Pressing Ctrl+C detaches the TTY gracefully

My Node.js script is calling process.exit() after it's done and is definitely ending as the docker container itself also stops (unable to docker-compose exec sh into the container after it's run). I've tried adding && poweroff or && halt to the end of my Dockerfile's CMD statement in attempt to make the container explicitly shut down after the script ends in hopes that would make it release the TTY but I still end up with a TTY attached to a now closed container.

[wyqydsyq]

I just realised I was running an old version (docker-compose@1.13.0) and upgraded to 1.16.0 and it now behaves as expected, thanks for that suggestion @shin- .

So I have these values for the service in my docker-compose.yml:

    tty: true
    stdin_open: false

The service executes my Node.js script in a TTY (so I get colour output etc) but still exits as soon as the script ends because it isn't holding STDIN open.

[capynet]

As wyqydsyq said, I upgraded to the latest version too and sudently tty: true stdin_open: false started working and docker does not hang anymore \o/

Docker version 17.12.0-ce, build c97c6d6
docker-compose version 1.19.0, build 9e633ef

[jvaill]

I'm still having this issue with docker-compose 1.18.0 on OS X.

[Belorus]

Same issue with 1.21.2 on Windows

[Nigrimmist]

The same on Windows

[jackemuk]

Same issue on Mac Version 18.06.1-ce-mac73 (26764)
Engine: 18.06.1-ce
Compose: 1.22.0
Machine: 0.15.0

[vikmn]

Doesnt seem to work for me in windows containers. Not tried linux containers.
Have tried
stdin_open: false
tty: true

as suggested by some comments as well. But i get a waiting cursor but cant seem to type any commands.
Any ideas on how the issue will be resolved or has been resolved?

[mmihaila]

For me worked
stdin_open: true
tty: true
and i was able to navigate in the system
root@9cbdf6d85199:/# ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

[marcellodesales]

@rgorodischer @mmihaila I'm currently experiencing this same problem in MacOS Version 18.06.1-ce-mac73 (26764) :(

[therussiankid92]

I've tried everything suggested in this post for Windows using Docker Toolbox, and no luck!

[glours]

@therussiankid92 do you have any reasons to use Docker Toolbox instead of Docker Desktop?

[therussiankid92]

Yes, I'm running on Windows Home, and Docker Desktop doesn't seem to be available for this version of Windows

[glours]

@therussiankid92 can you fill a new issue with as much details as possible ( Docker Toolbox version, docker engine & cli version, docker compose version...)?

[glours]

@therussiankid92 maybe a good news for you if you have a Windows 10 Home

https://twitter.com/sferquel/status/1234540699548364802

[therussiankid92]

Thats good, thanks a lot for the reply. I'll give it a try and see what happens. Will update both issues.

…

On Mon, Mar 2, 2020, 20:51 Guillaume LOURS ***@***.***> wrote: @therussiankid92 <https://github.com/therussiankid92> maybe a good news for you if you have a Windows 10 Home [image: Screen Shot 2020-03-02 at 8 50 27 PM] <https://user-images.githubusercontent.com/705411/75711951-7b979380-5cc7-11ea-86ad-321899878969.png> https://twitter.com/sferquel/status/1234540699548364802 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3106?email_source=notifications&email_token=AJCV7OXFBJBXCPSXRHGLET3RFQE2TA5CNFSM4B5XXCAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQWLJY#issuecomment-593585575>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJCV7OQ5ZXCFJMMV7MCZ7LLRFQE2TANCNFSM4B5XXCAA> .

[mikevoronov]

Also stumbled with such a problem on Mac Catalina with latest docker. Are there any workaround for MacOS? Tried all combinations for stdin_open, tty.

[InteNs]

this should probably be reopened because it's still happening to me and other people.

docker-compose logs -f <service> stops displaying new logs after 60 seconds of inactivity when tty: true