#docker-dev

is there any strategy to nsenter a running container that does not contain any interactive shell binaries like /bin/sh?

mgoelzer: nsenter -F

wrong

just use nsenter -t <pid> ... -- programm

Mic92: sorry, i'm confused. doesn't program need to be an executable binary already inside the container? my problem is, i don't have a /bin/sh inside the container.

sudo nsenter --target $PID --mount --uts --ipc --net --pid -F /bin/ls

nsenter: failed to execute /bin/ls: No such file or directory

doesn’t: docker exec <containerID> <program> work?

duglin: it's the same issue, isn't it? i don't have a <program> inside the container to run. sorry if i am not explaining this well...

well, w/o a program to run, what do you want to do? :-)

mgoelzer: do you want to run, which is not in the container?

i want to poke around the container's file system, but it's Dockerfile is "FROM golang:1.3" so there is no shell or other executable tools inside the image

“poke around” means use “sh”, right? no sh, no can do

i want to run /bin/sh, but because there is no /bin/sh inside the container, i'm asking if i can provide the /bin/sh on the host or somethign like that

duglin: yes, that's what i mean. so, it's impossible to do anything with a running container if it has no /bin/sh? no way to copy in an external /bin/sh from the host?

if we had “docker cp <host> <container>” then you could copy sh into it

mgoelzer: you nsenter like real men shave

but that PR isn’t merged yet

duglin: yes! that's what i want. bummer that it does not exist

mgoelzer: you skip --mount

And just change to the root directory of the container manually

true you could mount it into the original container

Mic92: thank you!!! yes, that's it, youre right

that fixed it

mgoelzer: uh, "FROM golang:1.3" should have a shell in it

tianon: really? i can't find one.

Mic92: hold on, though, if i remove --mount, what do i do next?

$ docker run -it --rm golang:1.3 sh

#

hmmm, you're right tianon

:D

mgoelzer: what filesystem backend do you use?

in docker

well, the container is just docker swarm. like do "docker pull swarm" and then "docker run -d -p 1234:2375 swarm manage token://whatever". now the container is running, but i cannot nsenter it

oh, swarm isn't FROM golang :)

swarm is just the single binary

Mic92: i'n not sure, what is the default

https://github.com/docker/swarm-library-image/b... :)

tianon: oh, ok, but i'm just looking at the Dockerfile in the root directory of docker swarm. first line is "FROM golang:1.3"

i guess that Dockerfile is somethign else

right :)

wait then what is this? https://github.com/docker/swarm/blob/master/Doc...

tianon, i just assumed that https://github.com/docker/swarm/blob/master/Doc... was the dockerfile for the swarm container, but i guess it's not?

nope, the Dockerfile linked from the Hub page for it is :) that's the main development Dockerfile, and I think there's an automated build of it somewhere too

https://registry.hub.docker.com/_/swarm/ << links at the top here go to the Dockerfiles for the tags :)

ah, dockerswarm/swarm is the automated build

but it builds from master :)

ok, i see now.

mgoelzer: use docker pker inspect

inspect

docker inspect

Shitty umts connection here

Mic92: what key am i looking for in inspect?

mgoelzer: Driver

got it: aufs

Mic92: so with aufs, is there a way to manually mount the container's filesystem after i run nsenter without the --mount option?

mgoelzer: wth are you trying to accomplish?

mgoelzer: I don't know how the aufs driver is implementend, but probably it is mounted in your host mount namespace already

cnf: at this point, it is just a curiousity question: given a running container with no /bin/sh binary, is there still a way to "poke around" inside the container using nsenter?

i consider "poking around" a failure

i don't do it

cnf: even just for debugging or exploration?

i have no need for it

cnf: but other people have

mgoelzer: mount | grep aufs

Mic92: hence why all my statements where prepended with "I"

I think docker should not be a blackbox no one can understand.

mgoelzer: i generally don't see the need to enter a container

Mic92: mount | grep aufs ==> no output

Mic92: it isn't a blackbox

docker is dead easy

except something does not work as expected

Mic92: "something"?

honestly, i'm just trying to learn here. nsenter seems like a good learning and exploration tool, but i guess you can only use it if you have included a /bin/sh or whatever diagnostic program you want in your container

mgoelzer: what do you need it for, though?

I see the engine shutdown hook doesn't clean up the unix socket (with Close()), is this intended (or a bug)? (I don't see that happening with signal handling either)

dmp42, ping

hello miminar :)

dmp42, hi

can you join #docker-distribution?

dmp42, yep

cnf: i think my original goal was to look at the environment variables in the container

mgoelzer: you could try the vfs driver.

mgoelzer: docker inspect ?

mgoelzer: then you have just plain folders instead of mounts

and if you want to see what files are in a container

cnf: yeah, i guess you're right that that's a better solution. but i also wanted to see the file system and possibly modify files

docker export <name>|tar -tvf -

mgoelzer: ^^^ shows the filesystem

cnf: i guess i didn't have a specific goal, just a general sense that i wanted to poke around

cnf: oh, that's a good idea

mgoelzer: the general point is for containers to be stateless

mgoelzer: so poking around and changing things manually tends to be counter to that

Mic92: i'll try vfs too. i need to read more about the different drivers

vfs is used for volumes

i don't think you can use it for layered fs

cnf: yeah, i do see what you mean

mgoelzer: use Dockerfiles to change things, and the line above to see what is in images you didn't make

mgoelzer: and you can always -v the file you are playing with into a container

cnf: yes, i think docker export / inspect is good solution for what i'm trying to do.

mgoelzer: also, you can do

docker inspect -f {{.Config.Entrypoint}} <name>

to just get one entry

cnf: vfs is also a graph driver

Sweet, now running rc3, and setup default ulimits and syslog logging, very nice

cpuguy83: nice!