[lxc-devel] [PATCH 0/5] Signal stuff v2 and some documentation

[Daniel Lezcano]

On 07/15/2010 10:07 PM, Ferenc Wagner wrote:
> Daniel Lezcano<daniel.lezcano at free.fr>  writes:
>
>    
>> On 06/09/2010 07:56 PM, Ferenc Wagner wrote:
>>
>>      
>>> here are basically the same patches, with some obvious errors corrected
>>> and some unrelated documentation added.  It actually survived some
>>> targeted testing in the past days and seems to behave as expected, ie.
>>>
>>> # lxc-start -n s -- sh -c "trap 'echo TERM' TERM; sleep 10"
>>>
>>> can be interrupted by Ctrl-C from the terminal (the sleep process does
>>> not ignore the SIGINT sent to the foreground process group by the OS),
>>> while a
>>>
>>> # pkill lxc-start
>>>
>>> does not terminate the sleep as the SIGTERM gets forwarded to the shell
>>> only, which reports it after the sleep expires.  This forwarding
>>> mechanism makes it possible to plug lxc into our batch queueing system.
>>>
>>>        
>> is it your last version or can I investigate with this patchset ?
>>      
> Yes, this is the version I've been using since I posted it.  I haven't
> ported it to latest git, but it shouldn't be hard.  It seems to do what
> I intended, but obviously interferes with the console handling, but that
> should be rethought anyway, as I see it.

Ok, thanks.  I will take the 2 first patches, so signal forwarding is 
done but without [tc]setpgrp for the moment.
I have a couple a patches on top of yours where when lxc-init receives a 
SIGTERM, it does like the usual 'init' process by sending a kill(-1, 
SIGTERM) followed by a kill(-1, SIGKILL) if all the processes do not 
exit after a small amount of time.

I just figured out, in your use case, you are using 'lxc-start -n foo 
<prog>'. You are getting ride of the child reaping (the kernel reparents 
orphan processes to the container's init). The purpose of lxc-init is to 
reap childs, mount /proc, /dev/shm, forward signals to process 2 and 
support daemons. Maybe you already noticed that, but maybe you should 
use the 'lxc-execute -n foo <prog>' (which spawns lxc-init). In this 
case, it would be more convenient to do [tc]setpgrp in lxc-init, so we 
solve the problem with the console.


> Basically, I feel like the container console from the user space PoV should be an alias for a
> terminal device, just like on a real system.  /dev/console isn't
> virtualized by the kernel, so it shouldn't be accessible from a
> container, although bind mounting it to some tty is an option in case
> some program uses it explicitly.

That was the first implementation but the '/sbin/init' process calls 
TIOCSCTTY, borrowing the tty to the current terminal.

>    In any case, the "console" presented
> by lxc-start should always be detachable, preferable even detached by
> default.
>    

Yep, I will send a matrix with a lxc-execute vs lxc-start vs start() 
common function vs console and hopefully we can find a nice way to fix 
this mess.

Thanks Ferenc,

   -- Daniel