On 07/15/2010 10:07 PM, Ferenc Wagner wrote: > Daniel Lezcano<daniel.lezc...@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 ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel