[PATCH 1/1] namespaces: introduce sys_hijack (v11)

Serge E. Hallyn serue at us.ibm.com
Fri Aug 1 10:38:17 PDT 2008


Quoting Bastian Blank (bastian at waldi.eu.org):
> On Fri, Aug 01, 2008 at 11:39:05AM -0500, Serge E. Hallyn wrote:
> > Quoting Bastian Blank (bastian at waldi.eu.org):
> > > Why is it not enough to use the pid of the ns creator? The ns cgroups
> > 
> > pids wrap around
> 
> Ups, yes.
> 
> > > But I think I have a different problem. Currently, namespaces are
> > > destructed if the last process using them exits. You change that, they
> > > will survive until the cgroup dies. Or is that cgroup destructed when
> > > there are no longer processes using the nsproxy? As the commit message
> > > speaks about "pid wraparound" as problem, I doubt that.
> > 
> > Correct.  Having the namespaces stick around, and being able to attach
> > to an empty container, was something Paul Menage had wanted IIRC.
> 
> It may produce problems with pid namespaces. The namespace is cleared if
> the child reaper dies and I'm not sure how well it behaves without a new
> one, which you can't create.
> 
> > But I'll leave that as is for now, until I hear something other than
> > "this is so wrong it isn't funny" from Pavel :)
> 
> I'm not sure if it is funny to add another piece which may hold
> filesystems open. Currently we can have different namespaces. All of
> them are attached to processes and can be removed with kill. Now this
> code adds another copy to an (automatically created) cgroup.
> 
> IMHO, the cgroup should be destructed automatically if the nsproxy is
> about to be die.

I certainly don't think your caution is unwarranted.  I like to keep the
refcounting in all of this as simple as possible.

However, it does place you at odds with one of the few people who has
expressed an existing need for this functionality :)

Paul, could you respond with precisely what your needs are?  I.e. do
you really only care about the network namespace sticking around?  Need
all of it?  Not need this at all anymore?

thanks,
-serge


More information about the Containers mailing list