On Mon, May 05, 2008 at 02:33:09PM -0700, Dave Leskovec wrote: > Daniel P. Berrange wrote: > > On Wed, Apr 30, 2008 at 11:38:01PM -0700, Dave Leskovec wrote: > >> This patch allows the lxc driver to handle SIGCHLD signals from exiting > >> containers. The handling will perform some cleanup such as waiting for > >> the container process and killing/waiting the tty process. This is also > >> required as a first step towards providing some kind of client container exit > >> notification. Additional support is needed for that but this SIGCHLD handling > >> is what would trigger the notification. > >> > >> libvirtd was already catching SIGCHLD although it was just ignoring it. I > >> implemented a mechanism to distribute the signal to any other drivers in the > >> daemon that registered a function to handle them. This required some changes to > >> the way libvirtd was catching signals (to get the pid of the sending process) as > >> well as an addition to the state driver structure. The intent was to provide > >> future drivers access to signals as well. > > > > The reason it was ignoring it was because the QEMU driver detects the > > shutdown of the VM without using the SIGCHLD directly. It instead detects > > EOF on the STDOUT/ERR of the VM child process & calls waitpid() then to > > cleanup. I notice that the LXC driver does not appear to setup any > > STDERR/OUT for its VMs so they're still inheriting the daemon's. If it > > isn't a huge problem it'd be desirable to try & have QEMU & LXC operate > > in the same general way wrt to their primary child procs for VMs. > > > > Regards, > > Daniel. > > stdout/err for the container is set to the tty. Containers can be used in a > non-VM fashion as well. Think of a container running a daemon process or a > container running a job as a part of a job scheduler/distribution system. > Wouldn't it be valid in these cases for the container close stdout/err while > continuing to run? Hmm, yes, that could be a reasonable use case. I see the key difference here is the the immediate child of libvirt *is* the startup application in the container which can be anything. So yes, we can't rely on its use of stderr/out, as we do with QEMU where the immediate child has defined behaviour Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list