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

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Oct 24, 2014

Contributor

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

Contributor

jessfraz commented Oct 24, 2014

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

@MichaelBitard

This comment has been minimized.

Show comment
Hide comment
@MichaelBitard

MichaelBitard 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 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

This comment has been minimized.

Show comment
Hide comment
@MichaelBitard

MichaelBitard Oct 25, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@MichaelBitard

MichaelBitard 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)

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

This comment has been minimized.

Show comment
Hide comment
@razic

razic 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 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

This comment has been minimized.

Show comment
Hide comment
@razic

razic Oct 28, 2014

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

razic commented Oct 28, 2014

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

@MichaelBitard

This comment has been minimized.

Show comment
Hide comment
@MichaelBitard

MichaelBitard Oct 28, 2014

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

MichaelBitard commented Oct 28, 2014

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

@razic

This comment has been minimized.

Show comment
Hide comment
@razic

razic Oct 28, 2014

Scratch that. Can't seem to reproduce.

razic commented Oct 28, 2014

Scratch that. Can't seem to reproduce.

@razic

This comment has been minimized.

Show comment
Hide comment
@razic

razic 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

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

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Jan 19, 2015

Contributor

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

Contributor

jessfraz commented Jan 19, 2015

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

@MichaelBitard

This comment has been minimized.

Show comment
Hide comment
@MichaelBitard

MichaelBitard 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

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

This comment has been minimized.

Show comment
Hide comment
@michaelsbradleyjr

michaelsbradleyjr Jan 23, 2015

I'm experiencing the same problem, docker 1.4.1.

michaelsbradleyjr commented Jan 23, 2015

I'm experiencing the same problem, docker 1.4.1.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Jan 23, 2015

Contributor

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

Contributor

cpuguy83 commented Jan 23, 2015

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

@michaelsbradleyjr

This comment has been minimized.

Show comment
Hide comment
@michaelsbradleyjr

michaelsbradleyjr 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).

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

This comment has been minimized.

Show comment
Hide comment
@MichaelBitard

MichaelBitard 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

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

This comment has been minimized.

Show comment
Hide comment
@michaelsbradleyjr

michaelsbradleyjr Feb 4, 2015

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

michaelsbradleyjr commented Feb 4, 2015

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

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 5, 2015

Contributor

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

Contributor

cpuguy83 commented Feb 5, 2015

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

@MichaelBitard

This comment has been minimized.

Show comment
Hide comment
@MichaelBitard

MichaelBitard 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).

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

This comment has been minimized.

Show comment
Hide comment
@michaelsbradleyjr

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

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

This comment has been minimized.

Show comment
Hide comment
@razic

razic 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).

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

This comment has been minimized.

Show comment
Hide comment
@dbabits

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

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

This comment has been minimized.

Show comment
Hide comment
@pikeas

pikeas commented Mar 11, 2015

+1!

@pwaller

This comment has been minimized.

Show comment
Hide comment
@pwaller

pwaller Mar 18, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@dbabits

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

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

This comment has been minimized.

Show comment
Hide comment
@pwaller

pwaller Mar 18, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@MichaelBitard

MichaelBitard Mar 19, 2015

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

MichaelBitard commented Mar 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@cyphar

cyphar Mar 23, 2015

Contributor

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

Contributor

cyphar commented Mar 23, 2015

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

@mouchtaris

This comment has been minimized.

Show comment
Hide comment
@mouchtaris

mouchtaris Mar 29, 2015

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

mouchtaris commented Mar 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Malet

Malet 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

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

This comment has been minimized.

Show comment
Hide comment
@cyphar

cyphar Mar 18, 2017

Contributor

I believe that opencontainers/runc#1356 was also blocking this, since @crosbymichael mentioned that docker exec had some issues with the new console-handling code.

Contributor

cyphar commented Mar 18, 2017

I believe that opencontainers/runc#1356 was also blocking this, since @crosbymichael mentioned that docker exec had some issues with the new console-handling code.

@mlaventure

This comment has been minimized.

Show comment
Hide comment
@mlaventure

mlaventure Mar 20, 2017

Contributor

the containerd v0.2.x branch in uncompatible with master runc. This change can't just be cherry-picked in the current version that containerd depends on.

We're mostly on maintenance mode on v0.2.x until 1.0 is ready, and given there seem to be a workaround, this is not critical enough IMHO.

But if someone is willing to do the update on the v0.2.x branch and test that again docker, a PR is more than welcome! 👼

Contributor

mlaventure commented Mar 20, 2017

the containerd v0.2.x branch in uncompatible with master runc. This change can't just be cherry-picked in the current version that containerd depends on.

We're mostly on maintenance mode on v0.2.x until 1.0 is ready, and given there seem to be a workaround, this is not critical enough IMHO.

But if someone is willing to do the update on the v0.2.x branch and test that again docker, a PR is more than welcome! 👼

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Mar 20, 2017

Contributor

@mlaventure I think its a simple fix to change v0.2.x to support this. We need the testing so its worthwhile to integrate it into that branch.

Contributor

crosbymichael commented Mar 20, 2017

@mlaventure I think its a simple fix to change v0.2.x to support this. We need the testing so its worthwhile to integrate it into that branch.

@ninrod

This comment has been minimized.

Show comment
Hide comment
@ninrod

ninrod Mar 20, 2017

Sorry, can you verify if I follow correctly?
Is a fix for this expected to land in the next official docker release?

ninrod commented Mar 20, 2017

Sorry, can you verify if I follow correctly?
Is a fix for this expected to land in the next official docker release?

@razic

This comment has been minimized.

Show comment
Hide comment
@razic

razic Mar 20, 2017

Hello everyone, I'm going to attempt to put some time into this, and see if I can get the fixes (wherever they may be required) in place, so we can close this issue once and for all. I'll report back here with an update as soon as possible.

razic commented Mar 20, 2017

Hello everyone, I'm going to attempt to put some time into this, and see if I can get the fixes (wherever they may be required) in place, so we can close this issue once and for all. I'll report back here with an update as soon as possible.

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Mar 21, 2017

Contributor

@ninrod i cannot guarantee anything but we will try

Contributor

crosbymichael commented Mar 21, 2017

@ninrod i cannot guarantee anything but we will try

@razic

This comment has been minimized.

Show comment
Hide comment
@razic

razic Mar 21, 2017

I spent a couple hours on this last night, mostly to get over the learning curve. I think I understand the majority of what I need to complete this. Most of the work is actually already done, and @crosbymichael has graciously offered to provide guidance as necessary. I'll give another update later tonight.

razic commented Mar 21, 2017

I spent a couple hours on this last night, mostly to get over the learning curve. I think I understand the majority of what I need to complete this. Most of the work is actually already done, and @crosbymichael has graciously offered to provide guidance as necessary. I'll give another update later tonight.

@razic

This comment has been minimized.

Show comment
Hide comment
@razic

razic Mar 22, 2017

Ok so a quick update; I think I can get this finished in a few days...

At this point I have my development environment up and running, such that I can iterate on the containerd codebase.

However, I've become stuck; I'll ping @crosbymichael tomorrow for help, but I can't seem to start an OCI bundle that was created via runc spec with ctr containers start... and I need to be able to use ctr containers exec to test my changes.

I'm using the docs here https://github.com/docker/containerd/blob/v0.2.x/docs/bundle.md to create the OCI bundle. I'm able to run the bundle using runc start (version v0.0.9), but as mentioned when trying to start the container using ctr, I get the following error:

$ ctr containers start redis $PWD
[ctr] rpc error: code = 2 desc = shim error: context deadline exceeded

Once I get this working, dropping in the changes should be as simple as consuming the https://github.com/crosbymichael/go-runc bindings that already support the new console functionality.

razic commented Mar 22, 2017

Ok so a quick update; I think I can get this finished in a few days...

At this point I have my development environment up and running, such that I can iterate on the containerd codebase.

However, I've become stuck; I'll ping @crosbymichael tomorrow for help, but I can't seem to start an OCI bundle that was created via runc spec with ctr containers start... and I need to be able to use ctr containers exec to test my changes.

I'm using the docs here https://github.com/docker/containerd/blob/v0.2.x/docs/bundle.md to create the OCI bundle. I'm able to run the bundle using runc start (version v0.0.9), but as mentioned when trying to start the container using ctr, I get the following error:

$ ctr containers start redis $PWD
[ctr] rpc error: code = 2 desc = shim error: context deadline exceeded

Once I get this working, dropping in the changes should be as simple as consuming the https://github.com/crosbymichael/go-runc bindings that already support the new console functionality.

@ninrod

This comment has been minimized.

Show comment
Hide comment
@ninrod

ninrod Mar 22, 2017

@razic this stuff is so advanced that I can't follow a word of what you've just said, but sounds promising. I'm eagerly waiting for this. Thanks for working on it.

ninrod commented Mar 22, 2017

@razic this stuff is so advanced that I can't follow a word of what you've just said, but sounds promising. I'm eagerly waiting for this. Thanks for working on it.

@razic

This comment has been minimized.

Show comment
Hide comment
@razic

razic Mar 24, 2017

Quick update... I was able to get a container running via ctr, so I think I may have gotten over that hump. I've been learning a lot about how the whole thing works (containerd-shim etc). I think I now have everything I need to be able to test my changes once I implement them. Will provide another update soon.

razic commented Mar 24, 2017

Quick update... I was able to get a container running via ctr, so I think I may have gotten over that hump. I've been learning a lot about how the whole thing works (containerd-shim etc). I think I now have everything I need to be able to test my changes once I implement them. Will provide another update soon.

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael May 8, 2017

Contributor

Fixed by #33007

Contributor

crosbymichael commented May 8, 2017

Fixed by #33007

@michaelsbradleyjr

This comment has been minimized.

Show comment
Hide comment
@michaelsbradleyjr

michaelsbradleyjr May 8, 2017

And there was much rejoicing.

michaelsbradleyjr commented May 8, 2017

And there was much rejoicing.

@ninrod

This comment has been minimized.

Show comment
Hide comment
@ninrod

ninrod May 8, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 9, 2017

Member

This will be in 17.06

Member

thaJeztah commented May 9, 2017

This will be in 17.06

@LinusU

This comment has been minimized.

Show comment
Hide comment
@LinusU

LinusU 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? :)

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

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 17, 2017

Member

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

Member

thaJeztah commented May 17, 2017

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

@LinusU

This comment has been minimized.

Show comment
Hide comment
@LinusU

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

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

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 17, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@LinusU

LinusU May 18, 2017

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

LinusU commented May 18, 2017

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

@zrml

This comment has been minimized.

Show comment
Hide comment
@zrml

zrml commented May 19, 2017

Great news @thaJeztah !

@ninrod

This comment has been minimized.

Show comment
Hide comment
@ninrod

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

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

This comment has been minimized.

Show comment
Hide comment
@razic

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

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

This comment has been minimized.

Show comment
Hide comment
@ninrod

ninrod Jun 28, 2017

is this released? where?

ninrod commented Jun 28, 2017

is this released? where?

@razic

This comment has been minimized.

Show comment
Hide comment
@razic

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

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

This comment has been minimized.

Show comment
Hide comment
@ninrod

ninrod Jun 29, 2017

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

ninrod commented Jun 29, 2017

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

@zrml

This comment has been minimized.

Show comment
Hide comment
@zrml

zrml Jun 29, 2017

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

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

workaround 'make dev/tmux_noattach' failing in some cases
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

workaround 'make dev/tmux_noattach' failing in some cases
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'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment