"Serge E. Hallyn" <se...@us.ibm.com> writes: > Quoting Daniel Lezcano (daniel.lezc...@free.fr): > >> Serge E. Hallyn wrote: >> >>> Quoting Ferenc Wagner (wf...@niif.hu): >>> >>>> Daniel Lezcano <daniel.lezc...@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. >> >> Ferenc is referring to the "unshare pid namespace" patchset of Eric. > > That's what I thought at first, but "lxc-unshare insist on forking" > didn't sound like it. But ok.
Sorry, I didn't make a distinction between fork and clone, my point was that lxc-unshare always creates a new process, which pretty much goes against the idea of unshare(), which is to unshare some namespace without creating a new process as opposed to what clone() does. At least this is how I understand it. Reading the referred patch "to unshare the pid namespace" revealed that it still requires a fork/clone, so it isn't what I'm after, which probably won't happen soon anyway, simply because real unsharing of the pid namespace is conceptually problematic. -- Thanks, Feri. ------------------------------------------------------------------------------ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
