[Lxc-users] lxc-unshare woes and signal forwarding in lxc-start

Serge E. Hallyn serue at us.ibm.com
Fri May 7 14:31:42 UTC 2010


Quoting Ferenc Wagner (wferi at niif.hu):
> Daniel Lezcano <daniel.lezcano at free.fr> writes:
> 
> > Ferenc Wagner wrote:
> >
> >> I can see that lxc-unshare isn't for me: I wanted to use it to avoid
> >> adding the extra lxc-start process between two daemons communicating via
> >> signals, but it's impossible to unshare PID namespaces, so I'm doomed.
> >   
> > There is a pending patchset to unshare the pid namespace, maybe for
> > 2.6.35 or 2.6.36 ...
> 
> Then why does lxc-unshare insist on forking?

I'm not sure what you mean - both the lxc version you mentioned, and
the newest commit in my git tree, go through lxc_clone(), which uses
clone, not fork.

> I thought unsharing the
> PID namespace was infeasible, because it changed the value returned by
> getpid(), but if more and more unsharing gets implemented, a
> PID-conserving helper would seem quite useful.  Maybe not for
> virtualizing full systems, but very much for insulating batch jobs under
> the supervision of some scheduler (like SGE for example).
> -- 
> Thanks,
> Feri.
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Lxc-users mailing list
> Lxc-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users




More information about the lxc-users mailing list