compose: `docker-compose up` hangs when tty parameter is true
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.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 31
- Comments: 48 (3 by maintainers)
Links to this issue
Commits related to this issue
- Don't allocate a pseudo-tty There's an erratic timeout error that makes this option confusing: https://github.com/docker/compose/issues/3106 — committed to lagartoflojo/osem by lagartoflojo 8 years ago
- Add docker timeouts for tty https://github.com/docker/compose/issues/3927 https://github.com/docker/compose/issues/3106 https://github.com/docker/compose/issues/2338 https://github.com/docker/docker-... — committed to astronomer/airflow by tedmiston 7 years ago
- remove tty:true from docker-compose template to prevent https://github.com/docker/compose/issues/3106 — committed to assembl/assembl by deleted user 7 years ago
- docker-compose.yml: Remove tty true from truffle. https://github.com/docker/compose/issues/3106 — committed to cryptomental/MarketProtocol by cryptomental 6 years ago
- docker-compose.yml: Remove tty true from truffle. to be removed... https://github.com/docker/compose/issues/3106 — committed to cryptomental/MarketProtocol by cryptomental 6 years ago
- docker-compose.yml: Remove tty true from truffle. to be removed... https://github.com/docker/compose/issues/3106 — committed to cryptomental/MarketProtocol by cryptomental 6 years ago
- remove tty:true from docker-compose template to prevent https://github.com/docker/compose/issues/3106 — committed to assembl/assembl by deleted user 7 years ago
- remove tty:true from docker-compose template to prevent https://github.com/docker/compose/issues/3106 — committed to assembl/assembl by deleted user 7 years ago
- remove tty:true from docker-compose template to prevent https://github.com/docker/compose/issues/3106 — committed to assembl/assembl by deleted user 7 years ago
I did this instead of
tty: true
:and then:
docker exec -it name_of_your_continaer /bin/bash
I’m still having this issue with docker-compose
1.18.0
on OS X.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
.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 whentty: true
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.I just realised I was running an old version (
docker-compose@1.13.0
) and upgraded to1.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
: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.
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: https://github.com/docker/compose/issues/2338#issuecomment-161691190
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.
@rgorodischer @mmihaila I’m currently experiencing this same problem in MacOS Version 18.06.1-ce-mac73 (26764) 😦
I am still facing the same issue. Do we have any resolution for this?
It still happens to me regularly with docker-compose 1.13 on OS X and tty: true.
Until this bug gets fixed you can set a big timeout to avoid the error:
@igorpejic, instead if I want to use
tty: true
in docker-compose.yml file because I need to usedocker attach name_container_web_1
for development tools what to do?I’m in the 60sec timeout problem right now.
@wakproductions I’m also working with a Rails app and enabled tty so that
byebug
would work.Not having access to
byebug
when stepping through my code is a real pain.I am encountering the same issue here. I have a Rails app which currently needs to be initiated via command line. My
docker-compose.yml
looks like this:When I do a
docker-compose up
I receive the following error:ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
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
The same on Windows
Same issue with
1.21.2
on WindowsSame issue but not error message after 1m
docker-compose.yml
Dockerfile
Not sure about the state of this issue but I hope this can help
PS. This is working for me:
Similar issue here - when setting
tty: true
in docker-compose.yml I get odd looking log output. It seems pretty random. Sometimes the log lines look ok. Other times, the first few characters are chopped off. The number of characters that get chopped off seems to be random. Additionally, sometimes the log lines contain colour, other times they don’t.Things do work properly when using
docker-compose run
instead ofdocker-compose up
however we are running a development stack comprising of many microservices and need to be able to stream the logout from all them together.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 therun
command opens up a TTY by default.On the other hand, if you want to attach to a process you need to set
tty
andstdin_open
to true. Whiletty: 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:What are options?
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?
My use case is I have a
service
in my compose file that is intended to run tests, log their output and exit.In order to get colors in the compose logging output I need
tty: true
.However, if that option is set the service will start, run the tests but then never exit even though the service’s
CMD
finished and exited.I feel dumb for asking this if anyone gets to it, What hte hell is tty used for i cant find information on it short of a telewriting function in unix?