[lxc-devel] [GIT] lxc branch, master, updated. 6f0a42008dab87e1c97bc71319c793315f87a328
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 6f0a42008dab87e1c97bc71319c793315f87a328 (commit) via 6fd1668e7f96c15b8688a0fa955e2c10bbc4785d (commit) via 83ee787579b400ee266d41d95d13913ca47df246 (commit) via f3304a29eb234cf1e90c74f9444f4d4de98e3e3a (commit) from d1c383f39064969b647fd632f8e6614b49fd6cf2 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 6f0a42008dab87e1c97bc71319c793315f87a328 Author: Daniel Lezcano Date: Tue Jul 13 14:51:45 2010 +0200 lxc-init finishes the remaining processes with SIGKILL If lxc-init receives a SIGALRM, a timeout, it kills all the processes of the container with SIGKILL. That will prevent the container to be stuck when one process ignore the SIGTERM signal. Each time a process exits, the timeout is resetted. Signed-off-by: Daniel Lezcano commit 6fd1668e7f96c15b8688a0fa955e2c10bbc4785d Author: Daniel Lezcano Date: Tue Jul 13 14:51:45 2010 +0200 lxc-init kills all processes with SIGTERM When lxc-init receives a SIGTERM, let's kill all the processes of the pid namespace with kill -1. So the exit of the container will happen gracefully with processes death cascade. Signed-off-by: Daniel Lezcano commit 83ee787579b400ee266d41d95d13913ca47df246 Author: Ferenc Wagner Date: Tue Jul 13 14:51:45 2010 +0200 generalize the name of the signal handler Signed-off-by: Ferenc Wagner Signed-off-by: Daniel Lezcano commit f3304a29eb234cf1e90c74f9444f4d4de98e3e3a Author: Ferenc Wagner Date: Tue Jul 13 14:51:45 2010 +0200 forward signals to the container init Signed-off-by: Ferenc Wagner Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/lxc_init.c | 48 ++-- src/lxc/start.c| 32 +++- 2 files changed, 61 insertions(+), 19 deletions(-) hooks/post-receive -- lxc -- 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
[lxc-devel] [GIT] lxc branch, master, updated. 1c4a945262b8d110c3f8e0655ca50cb05d383c74
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "lxc". The branch, master has been updated via 1c4a945262b8d110c3f8e0655ca50cb05d383c74 (commit) from 6f0a42008dab87e1c97bc71319c793315f87a328 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 1c4a945262b8d110c3f8e0655ca50cb05d383c74 Author: Daniel Lezcano Date: Mon Jul 19 16:04:41 2010 +0200 Remove dead code This function is no longer used. Signed-off-by: Daniel Lezcano --- Summary of changes: src/lxc/state.c |8 1 files changed, 0 insertions(+), 8 deletions(-) hooks/post-receive -- lxc -- 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
Re: [lxc-devel] a container can remount ro the host's mount point
On 04/01/2010 06:42 AM, Michael H. Warfield wrote: > Daniel, > > I'm going to top post here because I've just discovered that we've got a > bigger problem here, related to this whole mess. A much bigger problem > having to do with bind mounts in general. > > This is the generalized case here, which results from the observation > that, if a host container sets its root directory to ro, then the mount > point for the container in the host is set to ro. > > In fact, this is true of any additional bind mounts in containers! > > Say I have (and I do have) a couple of partitions which are shared > between certain containers, say for common data (somewhat risky, but I > eventually want to / hope to make them ro anyways). I was investigating > the whole read-only bind mount morass when I encountered this... > > So in the host, I have a partition, say /export, and I bind mount that > into the containers as /export in their space. Maybe I would like to > eventually have this as ro in some of them, maybe not. IAC, if I do a > remount in any of the containers, the changes are propagated outside of > the container to the host and to all the other containers! So if I do a > "mount -o remount,ro /export" in container A, the host and all the other > containers now have /export as ro as well. There's all kinds of concern > there, beyond merely the potential for mayhem by some practical joker in > one container. What if I had some of these mounted ro (with the > appropriate patch that was mentioned in another thread, I know you can't > do it yet in the released code). Can one container accidentally remount > the other containers rw? Yuck! What's worse... If I set that mount ro > in the host, I damn well don't want the container to be about to remount > it rw merely by doing a remount (that may be another can of worms). > > Just some thoughts, but this seems to be a mess and may even require > some kernel work with those bind mounts to fix. This was tested on a > 2.6.32 kernel. > It seems to be fixed now. I tried the example you gave and the mount rw option is not propagated to the other containers. Tested on ubuntu 10.04, kernel 2.6.32-23-generic and lxc 0.7.1. Do you confirm Michael ? Thanks -- 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
Re: [lxc-devel] [PATCH 0/5] Signal stuff v2 and some documentation
Daniel Lezcano writes: > On 07/15/2010 10:07 PM, Ferenc Wagner wrote: > >> Daniel Lezcano 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 > '. 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 ' (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
