Docker tty is not a tty with docker exec #8755

Open
MichaelBitard opened this Issue Oct 24, 2014 · 100 comments

Projects

None yet
@MichaelBitard

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
Contributor

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

@MichaelBitard

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

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

@MichaelBitard

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
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
razic commented Oct 28, 2014

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

@MichaelBitard

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

@razic
razic commented Oct 28, 2014

Scratch that. Can't seem to reproduce.

@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
Contributor

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

@MichaelBitard

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

I'm experiencing the same problem, docker 1.4.1.

@cpuguy83
Contributor

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

@michaelsbradleyjr

@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

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

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

@cpuguy83
Contributor
cpuguy83 commented Feb 5, 2015

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

@MichaelBitard

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

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

@jessfraz jessfraz added bug black-belt improvement and removed bug labels Feb 26, 2015
@pikeas
pikeas commented Mar 11, 2015

+1!

@pwaller
Contributor
pwaller commented Mar 18, 2015

I've just hit this. It's blocking me from sharing my environment with another developer in realtime, which is a problem.

@dbabits
dbabits commented Mar 18, 2015

This is what I do now:
run tmux on the docker host, not inside docker, and docker session in one of tmux's windows.
this achieves my goal explained above.

@pwaller
Contributor
pwaller commented Mar 18, 2015

Unfortunately I run coreos and running tmux on the host is not desirable, because I don't want to modify the host image at all, just run docker images for everything. This bug impedes that.

On 18 March 2015 22:17:15 GMT+00:00, dbabits notifications@github.com wrote:

This is what I do now:
run tmux on the docker host, not inside docker, and docker session in
one of tmux's windows.
this achieves my goal explained above.


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

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@MichaelBitard

I have a workaround :

docker exec -ti `your_container_id` script -q -c "/bin/bash" /dev/null

Ok, it's an ugly one, but with it you can use tmux when you use docker exec

@cyphar
Contributor
cyphar commented Mar 23, 2015

Things like sudo and su are also broken by not having a tty in the container.

@mouchtaris

Also pacman in Arch fails with

error: GPGME error: Inappropriate ioctl for device

because of TTY 404.

Work around by putting pacman in pipe mode, like

pacman -Syu | cat
@Malet
Malet commented Apr 8, 2015

Also having this issue (when trying to run tmux):

Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.4.1
Git commit (client): a8a31ef
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.4.1
Git commit (server): a8a31ef
@larsr
larsr commented Apr 28, 2015

I also have this issue. I want to share a GNU Screen session among two developers in the same docker instance. Thanks to @MichaelBitard (Mars 19) for the temporary work-around!

@aidanhs
Contributor
aidanhs commented Apr 29, 2015

I can only assume that this is what means page up and down don't work in less (the script hack doesn't work).

@razic
razic commented May 11, 2015

Found another instance where this is a pain in the ass...

docker-machine ssh "docker run -ti ubuntu bash"
time="2015-05-11T19:15:20Z" level=fatal msg="cannot enable tty mode on non tty input"
FATA[0000] exit status 1

You can allocate TTY by wrapping the original command with script, as mentioned in the previous comments.

@razic
razic commented May 13, 2015

A super simple example to reproduce:

docker exec -ti $CONTAINER_NAME tty
not a tty

And again, the workaround:

docker exec -ti $CONTAINER_NAME script -qc 'tty' /dev/null
/dev/pts/0

Believe it or not, this actually has a significant effect. For example, the cd command will fail without tty allocation.

@LK4D4
Contributor
LK4D4 commented May 13, 2015

Fun stuff that test -t 0 returns zero in exec.

@LK4D4
Contributor
LK4D4 commented May 13, 2015

So isatty returns 1 for STDIN_FILENO, but ttyname returns NULL.
And more fun stuff: errno isn't set on ttyname.

@LK4D4
Contributor
LK4D4 commented May 13, 2015

This is because there is no /dev/pts/ files inside container mount namespace.

@cyphar
Contributor
cyphar commented May 14, 2015

@LK4D4 It's because things like su run readlink(2) on the magic symlinks in /proc/self/fd/ to see if they are a TTY. This is also done by ttyname AFAIK (I probably should test this). However, it is not really a good indicator of whether an fd is a tty if the symlinks inside /proc/self/fd/ are not pointing to real locations on the filesystem.

@LK4D4
Contributor
LK4D4 commented May 14, 2015

@cyphar Yup, it is really tty, but tty tool using ttyname first, so it fails.

@cyphar
Contributor
cyphar commented May 15, 2015

I'd ask if we should send a whole bunch of upstream patches to fix this, but I have my doubts that they'd land (or even solve this problem for us in the next few years). Is there a way we can create the pts inside the container's mount namespace, so the tty magic symlinks aren't broken?

@LK4D4
Contributor
LK4D4 commented May 15, 2015

@cyphar I think it is possible to do if mount outside /dev/pts/<num> to containers dev in nsexec.c like we mounting it to /dev/console for main process.
Or it is possible to use container's devpts, but we need somehow to take fd from inside mount namespace back to docker.

@marvinpinto marvinpinto added a commit to marvinpinto/kitchensink that referenced this issue May 17, 2015
@marvinpinto marvinpinto Create a tmux wrapper to work around docker/docker#8755 a02f1a9
@andrefernandes

The docker Windows client (from Boot2Docker) runs ok ("docker run --rm -ti ...") on a Windows text prompt, but fails with this very same error when called from CygWin.

@thaJeztah thaJeztah removed the os/windows label May 21, 2015
@thaJeztah
Member

@andrefernandes that's a different issue. This issue is specifically for docker exec. What you're describing is probably (related to) this issue: #12469

@cyphar
Contributor
cyphar commented May 21, 2015

@andrefernandes This is a server-side issue, it's because TTY allocation on the Linux host isn't being done by us correctly. It also sounds like your issue is not related to this.

@senorsmile

Just found this issue after having issues with tmux and su. Has anyone come up with any patches yet?

@razic
razic commented May 28, 2015

@senorsmile Did you read the previous comments? There are workarounds.

@senorsmile

I have read the previous work arounds, but haven't gotten any of them (yet)
to properly start up the container with what I need running while enabling
me to use things like tmux via docker exec.

On Thu, May 28, 2015 at 2:40 PM Zachary Adam Kaplan <
notifications@github.com> wrote:

@senorsmile https://github.com/senorsmile Did you read the previous
comments? There are workarounds.

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

@razic
razic commented May 28, 2015

There is definitely a working solution to this problem, however unideal it may be. I'm not sure why you can't get it to work, especially given that you haven't posted any of your actual code. You may have better luck asking a friend or sitting in IRC. If you want to send me an email with your code, I'll be more than happy to look at it and see if I can't figure out why it doesn't work for you.

@senorsmile

I have figured out what I was doing. For some reason I kept reading that the docker RUN had to have the 'script /dev/null' call when starting the container. But, that's not it. It's only required for the docker exec. The workaround is now working for me. Thanks!

@linas
linas commented Jun 8, 2015

hitting this with lxc

@jessfraz
Contributor
jessfraz commented Jun 8, 2015

That's impossible you can't use exec w lxc

On Monday, June 8, 2015, Linas VepΕ‘tas notifications@github.com wrote:

hitting this with lxc

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

@linas
linas commented Jun 8, 2015

if you say so.

@razic
razic commented Jun 8, 2015

@linas Can you expand a bit? I'm curious as to why there seems to be a misunderstanding with exec and lxc.

@linas
linas commented Jun 8, 2015

The lxc equivalent is "lxc-attach" and when you lxc-attach to a running container, there is no tty. Same error messages, same workaround.

@jessfraz
Contributor
jessfraz commented Jun 8, 2015

That is not a bug with "docker exec" then... You cannot run docker exec with the lxc driver

@razic
razic commented Jun 8, 2015

Great, well at least we're getting somewhere. Perhaps we can use this as a clue to fix the underlying issue.

@cyphar
Contributor
cyphar commented Jun 9, 2015

The underlying issue is that we allocate a PTY outside the container's mount namespace (so the PTY devices aren't inside the container's /dev partition), so the pseudomagical /proc/self/fd/{0,1,2} symlinks are "broken". This breaks the way that things like su check if it's being run in a TTY --stat(ttyname(0)) or similar.

@LK4D4
Contributor
LK4D4 commented Jun 9, 2015

Yes, and for main process we mount pty inside as /dev/console.

@cyphar
Contributor
cyphar commented Jun 10, 2015

@LK4D4 Which we don't do for docker exec processes, right?

@LK4D4
Contributor
LK4D4 commented Jun 10, 2015

@cyphar No, it should be in nsenter/nsexec.c before joining mount namespace.

@cyphar
Contributor
cyphar commented Jun 10, 2015

@LK4D4 If you're referring to namespaces/nsenter/nsenter.c, I don't think we do. We just dup2 the console fd over {0,1,2} and we don't mount it in the child's namespace. If we do mount it in the child's namespace, we should be reopening the fd before we dup2 but after we mount (preferably after we fork too) so that the symlinks aren't broken.

@LK4D4
Contributor
LK4D4 commented Jun 10, 2015

@cyphar Yeah, I mean that we should, but we don't :)

@cyphar
Contributor
cyphar commented Jun 10, 2015

@LK4D4 Yup. If you want, I can write a PR to fix this. We actually can't mount it as /dev/console (that's reserved for the main process, no?), we'd have to mount it under /dev/pts/*. We should do the mount shenanigans inside namespace/nsenter/nsenter.c and not update the Go portion at all.

@jboesl
jboesl commented Jul 3, 2015

Just wanted to note I'm hitting this issue too with nano. Using nsenter instead of 'docker exec' it works fine.

@pwaller
Contributor
pwaller commented Jul 3, 2015

@cyphar I suspect that your suggestion of mounting it under /dev/pts/* won't work. For one, you'll find you can't bind mount anything in /dev/pts because it's a special filesystem which doesn't allow file creation. For two, even if you could bind mount it, if a process inside the container created lots of pseudoterminals, it could end up colliding. That's because the devpts filesystem is namespaced (due to the newinstance option) and maintains its own numbering. I now believe may be enough information in #11462 to fix this issue.

@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Jul 6, 2015
@gschlager gschlager Add a workaround for missing tty on launcher enter fad9b54
@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Jul 8, 2015
@gschlager gschlager Add a workaround for missing tty on launcher enter 3337c0e
@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Jul 28, 2015
@gschlager gschlager Add a workaround for missing tty on launcher enter c41f5e0
@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Jul 31, 2015
@gschlager gschlager Add a workaround for missing tty on launcher enter 72572c8
@ehazlett ehazlett added a commit to ehazlett/.dotfiles that referenced this issue Sep 2, 2015
@ehazlett ehazlett update devbox launch script to avoid docker/docker#8755
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
2bb2eba
@tiangolo

I'm not sure this is the same problem I was trying to solve, but nevertheless I will share it with you. I guess it's only relevant if you are using Windows.

I wrote a simple workaround / quick fix to allow using Docker Toolbox from Babun, it may help some of you:

https://github.com/tiangolo/babun-docker

With that you can keep using your docker commands as normal.

And if you are using Cygwin, you should use Babun, a very improved version of Cygwin.


You just have to run one command to setup everything. Although I encourage you to check the source code before running any script (including mine) in your terminal.

Inside, it installs and sets up winpty, and tries to start your default docker-machine VM and set up its environment.

Maybe it gets more relevant now since newer versions of Docker Toolbox come with Git 2.5, which uses mintty and has the same problem of "cannot enable tty mode on non tty input" as in Babun.

@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Oct 15, 2015
@gschlager gschlager Add a workaround for missing tty on launcher enter 4fd312a
@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Oct 21, 2015
@gschlager gschlager Add a workaround for missing tty on launcher enter 797325e
@runcom
Member
runcom commented Oct 30, 2015

@cyphar are you still working on nsexec to mount pts in exec?

@cyphar
Contributor
cyphar commented Oct 31, 2015

@runcom, no sorry. I looked at it, from what I can see you'd need to come up with some way of accessing ptmx in the devpts of the container in the host so you can make a master and slave pty for the process. Unfortunately, we create then unmount it.

@GordonTheTurtle

USER POLL

The best way to get notified when there are changes in this discussion is by clicking the Subscribe button in the top right.

The people listed below have appreciated your meaningfull discussion with a random +1:

@sjfloat
@jmreicha

@gentili
gentili commented Nov 22, 2015

So I'm hitting this with centos:7 and ubuntu:14.04 containers, but not with centos:6 image

centos:6

docker2:~/git/docker⟫ docker run --name "foo" -ti centos:6 /bin/bash 
[root@238531079dc9 /]# tty
/11

docker2:~⟫ docker exec -ti "foo" /bin/bash
[root@238531079dc9 /]# tty
/dev/pts/13

ubuntu:14.04

docker2:~⟫ docker run --name "foo" -ti ubuntu:14.04 /bin/bash                                                               
root@2514de9fb217:/# tty
/dev/console

docker2:~⟫ docker exec -ti "foo" /bin/bash
root@2514de9fb217:/# tty
not a tty

So this looks like an issue with the contents of the image rather than docker itself. Something about the lxc hooks in the user space libs or scripts?

@pwaller
Contributor
pwaller commented Nov 23, 2015

@gentili: unfortunately your discovery only amounts to a difference between the behaviour of tty in centos6 vs ubuntu:14.04. There is still not a functional tty inside the exec - just do ls -la /proc/self/fd/0 and see that it's a broken link pointing to a pts which doesn't exist.

If you run strace, you can see the difference in behaviour. Ubuntu does this:

readlink("/proc/self/fd/0", "/dev/pts/12", 4095) = 11
stat("/dev/pts/12", 0x7fffa84b3a10)     = -1 ENOENT (No such file or directory)

(Then it iterates over a load of devices in /dev before finally giving up). And CentOS:

readlink("/proc/self/fd/0", "/dev/pts/7", 4095) = 10
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 7), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8db98c3000
write(1, "/dev/pts/7\n", 11/dev/pts/7
)            = 11
@cyphar
Contributor
cyphar commented Nov 23, 2015

@pwaller Precisely, because the actual bug we're dealing with is that certain standard libraries assume that the symlinks in /proc/self/fds/ must be valid symlinks. Clearly CentOS does this properly (although, I don't like the fact that in docker run you get /11 which is invalid), but we need to fix this for all containers.

@pwaller
Contributor
pwaller commented Nov 23, 2015

Uh, is assuming /proc/self/fds is a valid symlink a bug? It seems not a bug to me, but a valid thing to do, if you want to know who your stdio is connected to under normal circumstances. My interpretation of the situation is that the problem here is that the pts doesn't exist inside the container (see also: #11462).

@cyphar
Contributor
cyphar commented Nov 23, 2015

The actual value of the symlink doesn't affect whether or not it works as a PTY, AFAICS it's an unnecessary restriction (a bug). But yes, the problem that causes the /proc/self/fds symlinks to be invalid is due to the way we deal with the pts namespace. I just don't agree that the assumption is correct (I'm fairly sure a more accurate way to check that the output is a TTY is to attempt to use the TTY-specific ioctls and see if the call fails).

@linas
linas commented Nov 23, 2015

Hey, lots of daemons dettach from their controlling terminal, and so their /proc/self/fds/0,1,2 will be closed. The issue here is that there is a reasonable expectation that attaching to a running container should work; i.e. the std fd's will not be closed.

Put it a different way: the issue is not whether /bin/bash is performing stat or testing for tty's with ioctl -- its that users expect to be able to get a tty and run bash in it, when attaching to a container, and when the users try this, they are disappointed that it didn't work.

@gentili
gentili commented Nov 23, 2015

@linas Agreed. docker exec --help says:

  -i, --interactive=false    Keep STDIN open even if not attached
  -t, --tty=false            Allocate a pseudo-TTY

So I don't think it's unreasonable to expect all the usual pty related machinery including /dev/pts/ to work as you'd expect.

@mrunalp
Contributor
mrunalp commented Dec 8, 2015

The problem is that the tty is created outside on the host and there is no reference to it in the container like how /dev/console is setup in the primary container. One options to fix this would be allocate and bind mount the devpts from the host in to the containers. I will try that out and report back.

@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Jan 14, 2016
@gschlager gschlager Add a workaround for missing tty on launcher enter 11dcef4
@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Jan 18, 2016
@gschlager gschlager Add a workaround for missing tty on launcher enter 6a93c4e
@gschlager gschlager added a commit to gschlager/discourse_docker that referenced this issue Jan 28, 2016
@gschlager gschlager Add a workaround for missing tty on launcher enter b393df7
@hervenicol

I came to open a bug because "docker exec -t" does not create the TERM variable, while "docker run -t" does.
I guess this is the same issue!

At least the doc could mention that "-t" has a slightly different effect with "run" and with "exec".

@cyphar
Contributor
cyphar commented Feb 23, 2016

@hervenicol That is an entirely separate issue (please open a separate issue for it). This issue is about docker exec not creating a TTY (this is unrelated to environment variables).

@aidanhs
Contributor
aidanhs commented Feb 23, 2016

@hervenicol @cyphar you're looking for #9299

@hervenicol

Thanks aidanhs. I added my comments in :)

@jsternberg jsternberg added a commit to influxdata/docker-docs that referenced this issue Jun 8, 2016
@jsternberg jsternberg Update influxdb documentation with clarifications
Removed the `docker exec` example since it doesn't appear to work
because of docker/docker#8755.
48ea652
@jsternberg jsternberg added a commit to influxdata/docker-docs that referenced this issue Jun 8, 2016
@jsternberg jsternberg Update influxdb documentation with clarifications
Removed the `docker exec` example since it doesn't appear to work
because of docker/docker#8755.
3881ab3
@jsternberg jsternberg added a commit to influxdata/docker-docs that referenced this issue Jun 8, 2016
@jsternberg jsternberg Update influxdb documentation with clarifications
Removed the `docker exec` example since it doesn't appear to work
because of docker/docker#8755.
b270a32
@linas
linas commented Aug 10, 2016

Quoting @brauner from lxc/lxc#554 "This is a known bug in glibc and @hallyn has send a fix to glibc (https://sourceware.org/ml/libc-alpha/2016-08/msg00307.html). It just needs to be applied."

Serge's fix is surprising and elegant.

@cyphar
Contributor
cyphar commented Aug 10, 2016

While @hallyn's fix helps solve the isatty() problem, there are other issues that we have inside runC that mean that even with that fix we still need some work here.

@linas
linas commented Aug 10, 2016

What other issues? Are you saying that you built Serge's fix, tried docker exec -ti mydockerinstance /bin/bash or the tmux variant, and it still doesn't work?

@cyphar
Contributor
cyphar commented Aug 10, 2016

runC doesn't create consoles inside the devpts of the container. I'm not entirely sure whether @hallyn's fix will fix tmux for Docker (but I know that lxc correctly handles the devpts problem -- I'm currently working on it in runC). I haven't tested it because custom-compiling glibc sounds like a bad idea. πŸ˜‰

There are also larger issues that are caused by the devpts handling in runC that will not be fixed by glibc (they have to be fixed within runC).

@linas
linas commented Aug 10, 2016

OK. Building glibc can be a pain if you've never done it before, but its not too bad. Its not like gcc.

@b-long
b-long commented Aug 10, 2016

@cyphar I've never done it, so I can't really speak to it, but I did find some info on the sourceware wiki, section Compile normally, run under new glibc :

Use this if you want to be able to run your application easily with the newly built libc and then again with the system libc for comparison.

Compile your test program, and invoke it with the newly loader you built. This is also how the make check runs tests. Note: if the executable under test resides in the current directory, don't forget to use ./ before the name.

Use either testrun.sh in the build directory e.g.

$ cd $HOME/build/glibc
$ ./testrun.sh /path/to/test/application

Is that at all helpful?

@j16180339887

For those who use Cygwin:
C:\cygwin64\Cygwin.bat works for me.

@icecrime
Member
@mrunalp
Contributor
mrunalp commented Sep 10, 2016 edited

This should be fixed with opencontainers/runc#1018

Sent from my iPhone

On Sep 9, 2016, at 6:05 PM, Arnaud Porterie notifications@github.com wrote:

Cc @crosbymichael!

β€”
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@tiangolo tiangolo pushed a commit to tiangolo/docs that referenced this issue Oct 13, 2016
@jsternberg jsternberg Update influxdb documentation with clarifications
Removed the `docker exec` example since it doesn't appear to work
because of docker/docker#8755.
7a475fd
@imam
imam commented Oct 14, 2016

For this issue, I just download winpty from https://github.com/rprichard/winpty/releases (the cygwin version one), then extract it to my git bash, then prefix 'winpty' to every command that have this issue . Maybe it'll help :).

@cyphar
Contributor
cyphar commented Oct 14, 2016

@imamassi script will also work. The fix exists within runc (opencontainers/runc#1018) but because it's quite a large change it's not been merged yet. We're hoping to get it merged by the end of the month (in time for OCI 1.0-rc2).

@ninrod
ninrod commented Oct 24, 2016 edited

I've just got hit by this for the second time. In the first hit, I wanted to connect to my docker instance using exec and then run a tmux session. No way to do that because we have no tty.

Now I've got hit for the second time. Trying to connect to a running emacs daemon via emacsclient. emacsclient gets angry at me saying: emacsclient: could not get terminal name. I've suspected tty shenanigans. So after Applying @MichaelBitard's solution (docker exec -tiyour_container_idscript -q -c "/bin/bash" /dev/null) it suddenly workded, but with some minor color artifacts.

@fernandoacorreia

With a container based on debian:8.6, to get both color support (e.g. for ls) and tmux working I had to use:

docker exec -it my-container env TERM=xterm script -q -c "/bin/bash" /dev/null
@thaJeztah
Member

@fernandoacorreia in docker 1.13, when you add -t, it will automatically set TERM=xterm see #26461

@gorivishal
gorivishal commented Dec 7, 2016 edited

+1

$ docker exec -it my_container bash << EOF
> echo "Test"
> EOF

I need to be running a bunch of commands inside the container once it's up here.

@cyphar
Contributor
cyphar commented Dec 7, 2016 edited

opencontainers/runc#1018 has been merged. This can be closed as soon as Docker vendors the latest commit of runc.

@razic
razic commented Dec 8, 2016

No way!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 🎊 πŸŽ‰

@thaJeztah
Member

ping @mlaventure ^^

@ninrod
ninrod commented Dec 8, 2016

hi @cyphar, little lost here. So will this be fixed in docker 1.13?

@cyphar
Contributor
cyphar commented Dec 8, 2016

@ninrod No, because it's too late for the changes to be merged into 1.13 (the RCs have already been released). I would expect it will be fixed in 1.14 (when Docker starts using the newer version of runC).

@mje-nz mje-nz referenced this issue in influxdata/influxdata-docker Dec 28, 2016
Closed

influxdb console arrow buttons don't work in docker container #26

@TheBiggerGuy TheBiggerGuy added a commit to TheBiggerGuy/flatpack-gqrx that referenced this issue Jan 25, 2017
@TheBiggerGuy TheBiggerGuy Fix for docker/docker#8755 dac7927
@TheBiggerGuy TheBiggerGuy added a commit to TheBiggerGuy/flatpack-gqrx that referenced this issue Jan 25, 2017
@TheBiggerGuy TheBiggerGuy Fix for docker/docker#8755 v2 2e8236b
@TheBiggerGuy TheBiggerGuy added a commit to TheBiggerGuy/flatpack-gqrx that referenced this issue Jan 25, 2017
@TheBiggerGuy TheBiggerGuy Fix for docker/docker#8755 v3 and not a good one :( 22e0d76
@jsternberg jsternberg added a commit to jsternberg/liner that referenced this issue Feb 13, 2017
@jsternberg jsternberg Return an error when the terminal reports zero columns and is refreshed
When used within a call to `docker exec -it` where the original
container does not have a TTY allocated to it (such as in
docker/docker#8755), the number of columns read from the `ioctl()` call
will be zero, but it will not return an error. If you call `Prompt()` or
`PasswordPrompt()` after this, the prompt will panic when it tries to
divide a number by the number of columns (which is zero).

This change detects when the number of columns returned is zero and
returns `ErrNoColumns` from the `PromptXXX` methods to avoid a panic and
so the application is able to deal with the problem more easily.
ee08c9f
@jsternberg jsternberg added a commit to jsternberg/liner that referenced this issue Feb 15, 2017
@jsternberg jsternberg Return an error when the terminal reports zero columns and is refreshed
When used within a call to `docker exec -it` where the original
container does not have a TTY allocated to it (such as in
docker/docker#8755), the number of columns read from the `ioctl()` call
will be zero, but it will not return an error. If you call `Prompt()` or
`PasswordPrompt()` after this, the prompt will panic when it tries to
divide a number by the number of columns (which is zero).

This change detects when the number of columns returned is zero and
returns `ErrPromptUnsupported` from the `PromptXXX` methods to avoid a
panic and so the application is able to deal with the problem more
easily.
00b1caf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment