Daniel Lezcano <daniel.lezc...@free.fr> writes: > 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.
Fine, that's enough for our immediate purposes. > I just figured out, in your use case, you are using 'lxc-start -n foo > <prog>'. Yes. > You are getting ride of the child reaping (the kernel reparents orphan > processes to the container's init). Sorry, I'm afraid I don't understand the "you are getting ride of the child reaping" part. Could you please rephrase that? > The purpose of lxc-init is to reap childs, mount /proc, /dev/shm, > forward signals to process 2 and support daemons. This isn't a particularly coherent set in my opinion, and neither is it documented, so I always regarded lxc-execute as a quick&dirty way to launch applications in a container. Reaping orphaned children is the usual task of init, so that's fine. Mounting this and that is purely convenience, lxc-start can do so just as well (and in a configurable way). Forwarding signals isn't something a usual init would do, and I wonder what purpose that serves. And what does "supporting daemons" mean exactly? Does lxc-start exit as soon as it's child exits, leaving possible other processes in the container running, and thus "leaking" a cgroup/namespace? It wouldn't seem like useful behaviour. > Maybe you already noticed that, but maybe you should use the > 'lxc-execute -n foo <prog>' (which spawns lxc-init). The above are just my general concerns with lxc-execute and co. My main reason for not using it is that SGE (the job scheduler I use) has a so called "shepherd" process for playing the role of init for each started job, so I meant lxc-init would be largely superfluous. > In this case, it would be more convenient to do [tc]setpgrp in > lxc-init, so we solve the problem with the console. I agree with the general idea of treating full-system and application containers differently in this respect. But I don't agree with tying this to lxc-execute, which isn't flexible enough for general use (for example, what if I don't want /proc in the container?). I still feel like console handling in lxc-start should be reworked. >> 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. Interesting. What does /sbin/init do exactly? It hasn't got a controlling terminal on my systems: $ ps j 1 PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND 0 1 1 1 ? -1 Ss 0 0:17 init [2] >> 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. Looking forward to it! :) -- Thanks, Feri. ------------------------------------------------------------------------------ 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