Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker tty is not a tty with docker exec #8755

Closed
MichaelBitard opened this issue Oct 24, 2014 · 127 comments
Closed

Docker tty is not a tty with docker exec #8755

MichaelBitard opened this issue Oct 24, 2014 · 127 comments

Comments

@MichaelBitard
Copy link

@MichaelBitard MichaelBitard commented Oct 24, 2014

When I enter a running docker with "docker exec -ti mydockerinstance /bin/bash"

tty returns: not a tty and tmux doesn't work.

I tried several things from #728:
docker exec -ti mydockerinstance sh -c "exec >/dev/tty 2>/dev/tty </dev/tty && /usr/bin/tmux -s /bin/bash"
getty tty
but nothing succeded.

@jessfraz
Copy link
Contributor

@jessfraz jessfraz commented Oct 24, 2014

what is $TERM set to, maybe try setting it to xterm ?

@MichaelBitard
Copy link
Author

@MichaelBitard MichaelBitard commented Oct 25, 2014

TERM is already set to xterm.

When I launch tmux -vvvv the tmux-client.log is empty but the tmux-server.log contains:

server started, pid 639
socket path /tmp/tmux-1000/default
new client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 14 from client 7
got 6 from client 7
fatal: tty_init: ttyname failed
@MichaelBitard
Copy link
Author

@MichaelBitard MichaelBitard commented Oct 25, 2014

When I try getty tty it just hang for a few seconds then give back the prompt, nothing changed

@MichaelBitard
Copy link
Author

@MichaelBitard MichaelBitard commented Oct 25, 2014

Ok, I managed to get something to work with script -c tmux but it's still a trick.

I really think this is a bug because:
If I do docker run --rm -ti my_image /bin/bash I get a tty and tmux works like a charm
(tty returns /dev/console)

But if I do docker run --rm -ti my_image then docker exec -ti /bin/bash this time it doesn't work, (tty returns not a tty)

@razic
Copy link

@razic razic commented Oct 28, 2014

i'm also running into this issue.

docker@boot2docker:~$ docker --version
Docker version 1.3.0, build c78088f

the only solution i found was to use script as well:

docker exec -ti container script /dev/null
@razic
Copy link

@razic razic commented Oct 28, 2014

I was actually able to run docker exec -ti container tmux this morning.

@MichaelBitard
Copy link
Author

@MichaelBitard MichaelBitard commented Oct 28, 2014

Wow, that's great, do you know what changed? Are you able to reproduce this?

@razic
Copy link

@razic razic commented Oct 28, 2014

Scratch that. Can't seem to reproduce.

@razic
Copy link

@razic razic commented Oct 28, 2014

I'm experiencing weird behavior with environment variables, tmux and vim...

For example, when I run:

docker exec -ti razic script /dev/null -c 'tmux'

The container launches. But, then I run vim .bash_profile inside a tmux pane, the colors are all screwed up:

screen shot 2014-10-28 at 11 04 53 am

If I run the same command above, but pass the -c option to tmux:

docker exec -ti razic script /dev/null -c 'tmux -c "vim .bash_profile"'

I get colors correct:

screen shot 2014-10-28 at 11 10 43 am

Seem like tmux's -c option loads the user environment correctly before running the vim command.

Basically I can only launch vim correctly from inside a tmux pane by logging into bash first:

docker exec -ti razic script /dev/null -c 'bash -ilc tmux'

or all manually:

docker exec -ti razic script /dev/null

then from inside the container:

 # colors are good without tmux
vim .bash_profile

# start tmux
tmux

# colors are not good in tmux
vim .bash_profile

# detach tmux
[detached]

# log in to bash
bash -il

# start tmux
tmux

# colors are good
vim .bash_profile
@jessfraz
Copy link
Contributor

@jessfraz jessfraz commented Jan 19, 2015

can you all let me know if this is still a relevant issue.

@MichaelBitard
Copy link
Author

@MichaelBitard MichaelBitard commented Jan 20, 2015

Yes, it's still relevant.

Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

Kernel Version: 3.13.0-36-generic
Operating System: Ubuntu 14.04.1 LTS
@michaelsbradleyjr
Copy link

@michaelsbradleyjr michaelsbradleyjr commented Jan 23, 2015

I'm experiencing the same problem, docker 1.4.1.

@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Jan 23, 2015

So, what image are you running, and with what run command, and what exec command?

@michaelsbradleyjr
Copy link

@michaelsbradleyjr michaelsbradleyjr commented Jan 23, 2015

@cpuguy83 I am running an image based on ubuntu:14.04 via the most recent boot2docker on a mac laptop (yosemite). I have experienced the same problem with all previous versions of docker / boot2docker which I've used in recent months.

Here are the steps which can be used to reproduce the problem.

# on the docker host
docker run -it --rm --name foo ubuntu:14.04 bash
# inside the container
apt-get update
apt-get install tmux
tmux

In another terminal on the host:

docker exec -it foo bash
# inside the container
tmux ls

The latter command will fail, and tmux will crash in the original terminal, in some cases killing the container altogether and/or turning it into a container-zombie (in which case one must boot2docker restart and then docker rm to get rid of it).

@MichaelBitard
Copy link
Author

@MichaelBitard MichaelBitard commented Jan 23, 2015

It seems that any image which has bash in it has the problem.

Step to reproduce:

docker run --name no_tty -dti ubuntu /bin/bash (or whatever)
docker exec -ti no_tty /bin/bash
tty -> not a tty
@michaelsbradleyjr
Copy link

@michaelsbradleyjr michaelsbradleyjr commented Feb 4, 2015

Any chance a fix for this bug will land in 1.5.0?

@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Feb 5, 2015

So what is the purpose of using docker exec to fire up a tmux session?

@MichaelBitard
Copy link
Author

@MichaelBitard MichaelBitard commented Feb 5, 2015

We use docker with ansible as a developer workstation, with this we have a
reproductible environment among all the developers
And as a developer, I use tmux. QED :)

If you are interested, here is a quickstarter
https://github.com/MichaelBitard/docker-ansible

Le Thu Feb 05 2015 at 5:27:03 PM, Brian Goff notifications@github.com a
écrit :

So what is the purpose of using docker exec to fire up a tmux session?


Reply to this email directly or view it on GitHub
#8755 (comment).

@michaelsbradleyjr
Copy link

@michaelsbradleyjr michaelsbradleyjr commented Feb 5, 2015

@cpuguy83 when working in "dev mode" with my containers, I generally pass -it to docker run and fire up tmux (i.e. when it seems useful to me to do so). It would be extremely useful (to me) to be able to fire up tmux in the context of exec -it, regardless of whether -it had been passed to run. At present, since the environment provided by exec is not a tty – even when invoked with -it flags (a pseudo-TTY is not actually allocated, apparently) – it's not possible to use it in this way. At the very least, perhaps the --help output of exec ought to be amended to indicate that its -it mode has limitations relative to run -it.

In other words, if this is a bug, it seems like it should be fixed. If it can't be fixed at present, or if it's a foreseen and/or intended limitation of exec, then an indication should be provided in the output of --help.

@razic
Copy link

@razic razic commented Feb 5, 2015

i also use docker for my development environment. this is why i run tmux
inside a container.

On Thu, Feb 5, 2015 at 1:04 PM, Michael Bradley notifications@github.com
wrote:

@cpuguy83 https://github.com/cpuguy83 when working in "dev mode" with
my containers, I generally pass -it to docker run and fire up tmux (i.e.
when it seems useful to me to do so). It would be extremely useful (to me)
to be able to fire up tmux in the context of exec -it, regardless of
whether -it had been passed to run. At present, since the environment
provided by exec is not a tty – even when invoked with -it flags (a
pseudo-TTY is not actually allocated, apparently) – it's not possible to
use it in this way. At the very least, perhaps the --help output of exec
ought to be amended to indicate that it's -it option has limitations
relative to run -it.


Reply to this email directly or view it on GitHub
#8755 (comment).

@dbabits
Copy link

@dbabits dbabits commented Feb 19, 2015

@michaelsbradleyjr +1 on Michael's comments.
To add a bit more to the use case:
I use a docker image as my dev environment.

The connection to the host often drops.

The image itself is designed to run monit(proc monitor), not bash, and I connect to it by way of -exec -ti bash

Then I would like to tmux attach and be back to where I left off.

If somebody has a better suggestion how to accomplish this, I appreciate your comments.

@pikeas
Copy link

@pikeas pikeas commented Mar 11, 2015

+1!

@crosbymichael
Copy link
Contributor

@crosbymichael crosbymichael commented May 8, 2017

Fixed by #33007

@michaelsbradleyjr
Copy link

@michaelsbradleyjr michaelsbradleyjr commented May 8, 2017

And there was much rejoicing.

@ninrod
Copy link

@ninrod ninrod commented May 8, 2017

awesome!!!! please gentleman, in what docker version can I grab this fix?

@thaJeztah thaJeztah added this to the 17.06.0 milestone May 9, 2017
@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented May 9, 2017

This will be in 17.06

@LinusU
Copy link

@LinusU LinusU commented May 17, 2017

Will this land in an edge release before that? Was it landed in 17.05.0-ce-mac11? Any pointers on where to check this? :)

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented May 17, 2017

No, this won't be in 17.05, only 17.06 and upward

@LinusU
Copy link

@LinusU LinusU commented May 17, 2017

Okay, thank you! Is there a release date set? Sorry for asking so many questions :) tried googling first but didn't find it, maybe I just a missed it though...

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented May 17, 2017

The version is YY.MM, and we target first week of the month, so first week of June, with release candidates before that

@LinusU
Copy link

@LinusU LinusU commented May 18, 2017

Ah, that's great to know, thank you!

@zrml
Copy link

@zrml zrml commented May 19, 2017

Great news @thaJeztah !

@ninrod
Copy link

@ninrod ninrod commented Jun 20, 2017

Hi @thaJeztah, is 17.06 going to land in in june or will it be rescheduled for july? if so, will it be 17.07 instead? just wan't to be sure regarding the version that will have this fix landed.

@razic
Copy link

@razic razic commented Jun 28, 2017

zacharys-pro:dev razic$ docker run --rm -t -d ubuntu bash
83c292c8e2d13d1b1a8b34680f3fb95c2b2b3fef71d4ce2b6e12c954ae50965a
zacharys-pro:dev razic$ Docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
83c292c8e2d1        ubuntu              "bash"              2 seconds ago       Up 1 second                             xenodochial_bardeen
zacharys-pro:dev razic$ docker exec -ti xenodochial_bardeen tty
/dev/pts/1
zacharys-pro:dev razic$ docker version
Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:31:53 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:51:55 2017
 OS/Arch:      linux/amd64
 Experimental: true

Great work everyone. Thank you very much.

@ninrod
Copy link

@ninrod ninrod commented Jun 28, 2017

is this released? where?

@razic
Copy link

@razic razic commented Jun 29, 2017

@ninrod I've included the version information in the output. This is fixed in version 17.06.0-ce, which is the most current stable version. If you are using Docker for Mac, you can simply restart the application, and you should be prompted to upgrade.

@ninrod
Copy link

@ninrod ninrod commented Jun 29, 2017

Oh. but this is not ready yet for docker for windows, right?

@zrml
Copy link

@zrml zrml commented Jun 29, 2017

just tested it on Docker-for-Mac latest and it works. I'm a happy man :-)

alikins added a commit to alikins/galaxy that referenced this issue Apr 10, 2018
For some cases, 'make dev/tmux' and specifically 'make
dev/tmux_noattach' will fail:

        make: *** [dev/tmux_noattach] Error 1

If 'tmux -v -v -v' is used, the error in the logfile is:

        fatal: tty_init: ttyname failed

This seems to be dependant on the version of docker
amongst other things.

moby/moby#8755 is a similar
issue with more detail and background.

But a workaround found there
(moby/moby#8755 (comment))
is to use the 'script' command to avoid the ttyname problems.

This commit uses that workaround for 'make dev/tmux'.
alikins added a commit to alikins/galaxy that referenced this issue Apr 10, 2018
For some cases, 'make dev/tmux' and specifically 'make
dev/tmux_noattach' will fail:

        make: *** [dev/tmux_noattach] Error 1

If 'tmux -v -v -v' is used, the error in the logfile is:

        fatal: tty_init: ttyname failed

This seems to be dependant on the version of docker
amongst other things.

moby/moby#8755 is a similar
issue with more detail and background.

But a workaround found there
(moby/moby#8755 (comment))
is to use the 'script' command to avoid the ttyname problems.

This commit uses that workaround for 'make dev/tmux'.
erszcz added a commit to esl/MongooseIM that referenced this issue Jan 24, 2019
`tty` might or might not work depending on whether a Docker container
or a Kubernetes pod is run with `-t` / `tty: true`.
Moreover, it depends on the flags passed initially to `run`
and also to flags passed later to `exec` when attaching
a shell to an already running container.
See moby/moby#8755 for details.

It's more convenient to just generate a random ID like relx does
in scripts it generates for releases.
erszcz added a commit to esl/MongooseIM that referenced this issue Jan 25, 2019
`tty` might or might not work depending on whether a Docker container
or a Kubernetes pod is run with `-t` / `tty: true`.
Moreover, it depends on the flags passed initially to `run`
and also to flags passed later to `exec` when attaching
a shell to an already running container.
See moby/moby#8755 for details.

It's more convenient to just generate a random ID like relx does
in scripts it generates for releases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet