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

[Daniel Lezcano]

Ferenc Wagner wrote:
> 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 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).
>   

The "unshare" of the pid namespace was not supposed to be implemented. 
The patchset is actually experimental and not for inclusion right now (I 
guess the author is too busy for the moment). It's something pending.

Another point is the property of the process doing unshare of the pid 
namespace. it won't be in the pid namespace itself, it has virtually the 
pid 0 and it will need to fork in order to have the child process to 
enter the pid namespace. The child process will be the pid 1 of pid 
namespace.