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.
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) ?
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.
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
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.
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.
It turns out that non-tty mode already disables the timeout indocker-py
. See https://github.com/docker/docker-py/issues/630 and docker/docker-py@70b921f8a399c83c51ca363cea685e6003abcdaf
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
@igorpejic : a bit ugly, but hey, it seems to work!
@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.
@mrkongo What hinders you from using my solution?
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?
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
I would use docker exec -ti
instead of attach. That way you don't have to modify your docker-compose.yml
to debug.
@ernestoalejo: That seems like a good option for now.
@dnephin: That won't work unfortunately. You need to be attached to the rails server process (with it in the foreground) in order for pry to drop you into a shell when it hits a breakpoint.
I have an issue with tty:true
also. added as a repository. Added logs to https://github.com/guneysus/docker-bug-report-3106/
If required, I file an seperate issue.
The problem with the tty:true
flag causes a faulty log.
I hope you can also reproduce this issue by running tty
target of Makefile.
make tty
and this generates two log file one is for stderr, the other is stdout.
Attaching to dockercomposestderrstdouttest_test_1
test_1 | t be go to stdout *****
test_1 | this must go to stderr
test_1 | ot:error *****
test_1 | WARNING:root:warning
dockercomposestderrstdouttest_test_1 exited with code 0
which should be
Attaching to dockercomposestderrstdouttest_test_1
test_1 | this must go to stdout
test_1 | this must go to stderr
test_1 | ERROR:root:error
test_1 | WARNING:root:warning
dockercomposestderrstdouttest_test_1 exited with code 0
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:
version: '2'
services:
web:
container_name: myapp
build: .
command: bundle exec rails c -e production
tty: true
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.
@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.
@tspangler My workaround is docker-compose run web rails c -e production
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 of docker-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.
Same issue as @mrfelton . docker-compose up
with tty: true
(14 services) log output get's "wierd" ... sometimes colored, characters missing from beginning of lines.
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?
Same issue but not error message after 1m
$ time docker-compose up --verbose
ompose.config.config.find: Using configuration files: ./docker-compose.yml
docker.auth.find_config_file: Trying paths: ['/Users/fmorales/.docker/config.json', '/Users/fmorales/.dockercfg']
docker.auth.find_config_file: No config file found
compose.cli.command.get_client: docker-compose version 1.10.0, build 4bd6f1a
docker-py version: 2.0.1
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j 26 Sep 2016
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=4.9.4-moby, Arch=amd64, BuildTime=2017-01-18T16:20:26.924957224+00:00, ApiVersion=1.25, Version=1.13.0, MinAPIVersion=1.12, GitCommit=49bf474, Os=linux, Experimental=True, GoVersion=go1.7.3
compose.cli.verbose_proxy.proxy_callable: docker info <- ()
compose.cli.verbose_proxy.proxy_callable: docker info -> {u'Architecture': u'x86_64',
u'BridgeNfIp6tables': True,
u'BridgeNfIptables': True,
u'CPUSet': True,
u'CPUShares': True,
u'CgroupDriver': u'cgroupfs',
u'ClusterAdvertise': u'',
u'ClusterStore': u'',
u'ContainerdCommit': {u'Expected': u'03e5862ec0d8d3b3f750e19fca3ee367e13c090e',
u'ID': u'03e5862ec0d8d3b3f750e19fca3ee367e13c090e'},
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_network <- (u'nodedockervolumes_default')
compose.network.ensure: Creating network "nodedockervolumes_default" with the default driver
compose.cli.verbose_proxy.proxy_callable: docker create_network <- (name=u'nodedockervolumes_default', enable_ipv6=False, ipam=None, labels=None, driver=None, attachable=None, internal=False, options=None)
compose.cli.verbose_proxy.proxy_callable: docker create_network -> {u'Id': u'dfd6501b5fbf199b946bec376b3b202b6090d81e89330d1985b99a92586b6385',
u'Warning': u''}
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=False, filters={u'label': [u'com.docker.compose.project=nodedockervolumes', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=nodedockervolumes', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- (u'nodedockervolumes_web')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
u'Author': u'',
u'Comment': u'',
u'Config': {u'ArgsEscaped': True,
u'AttachStderr': False,
u'AttachStdin': False,
u'AttachStdout': False,
u'Cmd': [u'node'],
u'Domainname': u'',
u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=nodedockervolumes', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.parallel.feed_queue: Pending: set([<Service: web>])
compose.parallel.feed_queue: Starting producer thread for <Service: web>
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- (u'nodedockervolumes_web')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
u'Author': u'',
u'Comment': u'',
u'Config': {u'ArgsEscaped': True,
u'AttachStderr': False,
u'AttachStdin': False,
u'AttachStdout': False,
u'Cmd': [u'node'],
u'Domainname': u'',
u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=nodedockervolumes', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- (u'nodedockervolumes_web')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
u'Author': u'',
u'Comment': u'',
u'Config': {u'ArgsEscaped': True,
u'AttachStderr': False,
u'AttachStdin': False,
u'AttachStdout': False,
u'Cmd': [u'node'],
u'Domainname': u'',
u'Entrypoint': None,
...
compose.service.build_container_labels: Added config hash: c934557cf7dce7737b3b7d5c1a0063296915c792f1912cd53f4b157c44959fe7
compose.cli.verbose_proxy.proxy_callable: docker create_host_config <- (cap_add=None, mem_swappiness=None, links=[], oom_score_adj=None, dns_search=None, pid_mode=None, log_config={'Type': u'', 'Config': {}}, cpu_quota=None, read_only=None, dns=None, volumes_from=[], port_bindings={}, security_opt=None, extra_hosts=None, cgroup_parent=None, network_mode=u'nodedockervolumes_default', shm_size=None, userns_mode=None, tmpfs=None, cap_drop=None, memswap_limit=None, restart_policy=None, devices=None, privileged=False, binds=[], sysctls=None, ipc_mode=None, mem_limit=None, group_add=None, ulimits=None)
compose.cli.verbose_proxy.proxy_callable: docker create_host_config -> {'Binds': [],
'Links': [],
'LogConfig': {'Config': {}, 'Type': u''},
'NetworkMode': u'nodedockervolumes_default',
'PortBindings': {},
'VolumesFrom': []}
compose.service.create_container: Creating nodedockervolumes_web_1
compose.cli.verbose_proxy.proxy_callable: docker create_container <- (tty=True, name=u'nodedockervolumes_web_1', image=u'nodedockervolumes_web', labels={u'com.docker.compose.service': u'web', u'com.docker.compose.project': u'nodedockervolumes', u'com.docker.compose.config-hash': 'c934557cf7dce7737b3b7d5c1a0063296915c792f1912cd53f4b157c44959fe7', u'com.docker.compose.version': u'1.10.0', u'com.docker.compose.oneoff': u'False', u'com.docker.compose.container-number': '1'}, host_config={'NetworkMode': u'nodedockervolumes_default', 'Links': [], u'Isolation': None, 'PortBindings': {}, 'Binds': [], 'LogConfig': {'Type': u'', 'Config': {}}, 'VolumesFrom': []}, environment=[], volumes={}, detach=True, networking_config={u'EndpointsConfig': {u'nodedockervolumes_default': {u'IPAMConfig': {}, u'Aliases': ['web']}}})
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {u'Id': u'dc5a45f56f3a1d60638bff66eebe836dde59191f8e9aed5c4c12b62f42115a44',
u'Warnings': None}
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- (u'dc5a45f56f3a1d60638bff66eebe836dde59191f8e9aed5c4c12b62f42115a44')
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> {u'AppArmorProfile': u'',
u'Args': [],
u'Config': {u'ArgsEscaped': True,
u'AttachStderr': False,
u'AttachStdin': False,
u'AttachStdout': False,
u'Cmd': [u'node'],
u'Domainname': u'',
u'Entrypoint': None,
u'Env': [u'no_proxy=*.local, 169.254/16',
...
compose.cli.verbose_proxy.proxy_callable: docker attach <- (u'dc5a45f56f3a1d60638bff66eebe836dde59191f8e9aed5c4c12b62f42115a44', stderr=True, stream=True, stdout=True)
compose.cli.verbose_proxy.proxy_callable: docker attach -> <generator object frames_iter at 0x103e5f3c0>
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- (u'dc5a45f56f3a1d60638bff66eebe836dde59191f8e9aed5c4c12b62f42115a44', u'nodedockervolumes_default')
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> None
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- (u'dc5a45f56f3a1d60638bff66eebe836dde59191f8e9aed5c4c12b62f42115a44', u'nodedockervolumes_default', ipv4_address=None, link_local_ips=None, ipv6_address=None, links=[], aliases=['web', u'dc5a45f56f3a'])
compose.parallel.feed_queue: Pending: set([])
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> None
compose.cli.verbose_proxy.proxy_callable: docker start <- (u'dc5a45f56f3a1d60638bff66eebe836dde59191f8e9aed5c4c12b62f42115a44')
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.cli.verbose_proxy.proxy_callable: docker start -> None
compose.parallel.parallel_execute_iter: Finished processing: <Service: web>
compose.parallel.feed_queue: Pending: set([])
Attaching to nodedockervolumes_web_1
compose.cli.verbose_proxy.proxy_callable: docker events <- (decode=True, filters={u'label': [u'com.docker.compose.project=nodedockervolumes', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker events -> <generator object _stream_helper at 0x1061f0320>
docker-compose --verbose up 0.49s user 0.14s system 0% cpu 1:04.10 total
md5-627df2ebdc369a27b2b0c9143febe403
version: '2'
services:
web:
tty: true
build: .
md5-87ac9b3e0f224f413f284cc5fcc58e07
FROM node:7
CMD ["/bin/bash"]
md5-6dac7045edc289566c96ad60527633e9
docker-compose run web /bin/bash
Are people still seeing this issue with the latest 1.12.0
release? I can't seem to trigger that timeout with the examples posted in that thread.
I can't trigger the timeout either.
It still happens to me regularly with docker-compose 1.13 on OS X and tty: true.
I am also experiencing this issue, in linux (ubuntu 16.04) with docker-ce 1.5 and, it seems, pretty much any version of docker-compose
I did some debugging and found that it came down to:
docker-compose
(via docker-py
) reading a frame size from the docker socket and getting some log output instead, result in it expecting a ~1700000000 byte chunkframes_iter
in docker-py
ignoring EOF while trying to read the socketfixing the latter will change this issue from a hang to an immediate exception abort. I don't know what is causing the former.
I am still facing the same issue. Do we have any resolution for this?
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.
Please make sure you are using 1.16
@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.
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.
I just realised I was running an old version ([email protected]
) 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.
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
I'm still having this issue with docker-compose 1.18.0
on OS X.
Same issue with 1.21.2
on Windows
The same on Windows
Same issue on Mac Version 18.06.1-ce-mac73 (26764)
Engine: 18.06.1-ce
Compose: 1.22.0
Machine: 0.15.0
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?
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
@rgorodischer @mmihaila I'm currently experiencing this same problem in MacOS Version 18.06.1-ce-mac73 (26764) :(
I've tried everything suggested in this post for Windows using Docker Toolbox, and no luck!
@therussiankid92 do you have any reasons to use Docker Toolbox instead of Docker Desktop?
Yes, I'm running on Windows Home, and Docker Desktop doesn't seem to be available for this version of Windows
@therussiankid92 can you fill a new issue with as much details as possible ( Docker Toolbox version, docker engine & cli version, docker compose version...)?
@therussiankid92 maybe a good news for you if you have a Windows 10 Home
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 notifications@github.com 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.pnghttps://twitter.com/sferquel/status/1234540699548364802
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/compose/issues/3106?email_source=notifications&email_token=AJCV7OXFBJBXCPSXRHGLET3RFQE2TA5CNFSM4B5XXCAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQWLJY#issuecomment-593585575,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJCV7OQ5ZXCFJMMV7MCZ7LLRFQE2TANCNFSM4B5XXCAA
.
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 when tty: true
Most helpful comment
I'm still having this issue with docker-compose
1.18.0
on OS X.