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

[Daniel Lezcano]

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.

http://git.kernel.org/?p=linux/kernel/git/ebiederm/linux-2.6.33-nsfd-v5.git;a=commit;h=a6d862ffdeca62c95f6a3e1a5ca7756e7fc9925a

But as I explained, it is not yet in mainline.

>> 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).