[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