Flagging as proposal, thanks for the "docs first" approach!

I'd feel more comfortable if there was a default --pid=namespaced (or something), making it a little more obvious that this flag changes the norm.

I don't understand the point

Why use a container if you don't want to be contained?

it allows the use of container images as a distribution mechanism - ie, will make the rpm format obsolete 🎉 :)

and you get a magical way to uninstall, or up/down grade a host's daemons

I would not go as far as saying make RPM obsolete. As you still need a packageing format for building your image. But yes, the point is to use docker images as a packaging format.

Turning off all namespaces except the mnt namespace is the goal. BTW CoreOS is doing this now but they just use the docker format and then run systemd-nspawn on the exploded image.

I would prefer to use native docker commands.

@rhatdan one thing that --pid=container:someother might be useful for, is to compose a set of services that might be managed by some kind of supervisor process with might have been coded container unaware (but with configurable spawn commands). But hey, i also want to have --fs=container:someother to let me compose a server with dynamic plugins.

This feature would allow the entire OS image to be modified on the fly without modifying running applications. If applications were smart enough to handle a restart in this situation, the base images and most of the applications could be restarted leaving key processes behind.

In one use case, we want to run OpenStack Nova and Libvirt in an upgrade, but keep all of the KVM processes between container restarts. This would allow libvirt to reconnect to the existing KVM processes, even after what would appear like a full container restart ;)

@sdake idk, i would take the opposite approach and think that docker should inspect the cgroup and kill off any tasks when the container stops or else ( if you do not understand what this means ) you will have processes that live on after docker reports that your container has stopped.

idk, what do you think?

@crosbymichael The reason to share PID namespaces between containers and between executions of the container tech is to allow the rest of the OS to upgrade seamlessly while critical applications launched from container daemons remain untouched. I get it is not very intuitive, which is why I think Dan suggested a special flag to get Docker to execute in this way.

I would argue you want both. I want all of the processes running in the container to exit on stopping the container, but I also could see allowing moving certain pids out of the container cgroup and letting them live on until killed.

Specifically we are looking at libvirt again running iwithin the container. We might want to reboot the libvirtd container but allow the virtual machines to continue running.

@rhatdan That WFM, would that be a different feature, or had you intended this feature to handle the "both" model?

@sdake I wanted this feature to handle both.

@crosbymichael

The problem I am seeing is if I do

docker run -ti --pid=host fedora /bin/sh

sleep 6000 &

^d

The process just hangs, and the container never exits. What I would like to do is realize that the primary pid has died and then send kill signals to all of the processes in the cgroup.

I think the problem is docker does not watch for a pid1 to die, it watches for the cgroup to get removed when all of the processes exit.

    oomKillNotification, err := libcontainer.NotifyOnOOM(state)

Is there a place where go gets a sigchild from Pid1 of the container?

Actually the cmd.Wait() will return after PID1 dies. We will then have to use the cgroup to freeze, send a sigkill to all remaining processes, unfreeze and wait for them to die.

Do you think it should be conditional that we nuke the cgroup or is it safe to do it every time?

Do you think that setting a parent death signal to SIGKILL work be enough if we using the host's PID namespace?

I found the place and updated the pull request, it now kills all processes if you are using the Host PID Namespace.

The patch I have is currently racy in that a ForkBomb could leave a process running.
I am not sure if the cgroup freeze will fix the problem, but I guess it is better then what I have now.

I'm updating docker with the latest changes from libcontainer with this change so we can move forward.

#10049

@crosbymichael updated

@icecrime can you review this one also?

This is looking good so far.

root@f9b5d1691ec2:/go/src/github.com/docker/docker# docker run --rm busybox ps aux
PID   USER     COMMAND
    1 root     ps aux
root@f9b5d1691ec2:/go/src/github.com/docker/docker# docker run --rm --pid host busybox ps aux
PID   USER     COMMAND
    1 root     bash
  496 root     docker -d -s vfs
  600 root     docker run --rm --pid host busybox ps aux
  615 root     ps aux
root@f9b5d1691ec2:/go/src/github.com/docker/docker#

LGTM

It would be nice to remove the NS suffix from the var names to make it more consistent with Ipc.

After being created on 2014-04-08 14:16:33, we can finally run crosbymichael/htop with this PR

sed s/pidns/pid done

LGTM for carry @crosbymichael
I don't know if the docs are OK from @fredlf's, @SvenDowideit's and @jamtur01's point of view.

Minor Docs comments but otherwise LGTM.

Fixed docs.

Closing in favor of #10080