[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 ...
> 
> Good to know, but I'd like to stick with 2.6.32 if possible.
> 
>>> But now I see that signal forwarding was just added to lxc-init, would
>>> you consider something like that in lxc-start as well?
>> It's the lxc-init process who forward the signals. The lxc-kill sends
>> a signal to the pid 1 of the container. When lxc-init is the first
>> process, it receives the signal and forward it to the pid 2.
> 
> Yes.
> 
>> In the case of lxc-start, let's say 'lxc-start -n foo sleep 3600'. The
>> sleep' process is the first process of the container, hence if you
>> lxc-kill -n foo <signum>' command, that will send the signal to
>> sleep'.
> 
> Sure, but it isn't me who sends the signals, but that who spawned
> lxc-start.  I'd like to use lxc-start a wrapper, invisible to the parent
> and the (jailed) child.  Of course I could hack around this by not
> exec-ing lxc-start but keeping the shell around, trap all signals and
> lxc-kill them forward.  But it's kind of ugly in my opinion.

Ok, got it. I think that makes sense to forward the signals, especially 
for job management. What signals do you want to forward ?