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

[Ferenc Wagner]

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.
-- 
Thanks,
Feri.