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

[Ferenc Wagner]

"Serge E. Hallyn" <serue at us.ibm.com> writes:

> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>
>> Serge E. Hallyn wrote:
>>
>>> 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.
>> 
>> 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.