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

Proposal: Support custom PID namespace #8568

Closed
ibuildthecloud opened this Issue Oct 14, 2014 · 7 comments

Comments

Projects
None yet
7 participants
@ibuildthecloud
Contributor

ibuildthecloud commented Oct 14, 2014

Currently you can do --net=host or --net=container:id. I propose we add --pid=host or --pid=container:id so that you can control what PID namespace is setup. The obvious use cause for such a thing is to run some monitoring tool that looks at processes in a container. A simple example is to run htop against the host or another container.

The technical implications of this proposal is that Docker will need to track the processes of the container and kill them based on the cgroup. Today if you stop/kill a container Docker will ensure the container PID 1 is killed. Once the PID 1 is killed, Linux will kill all other processes in the PID namespace. To support this behaviour I propose that Docker mimics the same behaviour with cgroups. This means that Docker stop/kill the container PID as it does today. Once the process is gone Docker should iterate all other processes in the cgroup and do a SIGKILL, as that is effectively what Linux does when a processes PID namespace goes away.

@IcE4k777

This comment has been minimized.

IcE4k777 commented Nov 6, 2014

I think this would be great. I have a current need right now where one application provides clustering functionality for other apps / slaves to join. I would like to be able to isolate the main app in one container and then have other apps in their own containers join the cluster if needed that is setup from the main app. Perhaps I am missing something and this could be doable already, however, I have seen no way to achieve this yet without being able to share the namespace(s), as the point of containers is indeed to isolate processes : )

@coderfi

This comment has been minimized.

coderfi commented Dec 29, 2014

Same here, in particular, I'm trying to run a MAPR client (via a hadoop command) inside a docker (with ---net=host) which is running on a MAPRFS data node.
Unfortunately, I keep running into what appears to be the MAPR library attempting to hit the the MAPR FileSystem process which is running on the host.
Since the client is isolated, it blows chunks.
The only way around this issue is to give the docker container its own ip address. This fools the MAPR driver into thinking the MAPR data node is NON-LOCAL. The data instead, flows through as regular IP traffic.
However, this defeats the optimization of accessing the data directly, and locally on that host. It also pretty much defeats other data locality optimizations that are available.
I might as well run the container on a remote VM!

@phemmer

This comment has been minimized.

Contributor

phemmer commented Jan 14, 2015

This was implemented in #10080

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Jan 14, 2015

done with --pid.

Thanks for the update @phemmer

@ibuildthecloud

This comment has been minimized.

Contributor

ibuildthecloud commented Jan 15, 2015

@crosbymichael Hate to be pedantic, but this shouldn't be closed as --pid=container:id doesn't exist yet. This could be closed if we never plan to implement it, but I think there is still a use case.

@crosbymichael

This comment has been minimized.

Member

crosbymichael commented Jan 16, 2015

@ibuildthecloud what is the use case?

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Jan 18, 2015

People looking for --pid=container:id; There's a new issue created for that here: #10163

@ederst ederst referenced this issue Mar 24, 2015

Open

Zombies #9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment