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.

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?

Dave Leskovec <dlesko(a)linux.vnet.ibm.com&gt; wrote: ... >>> +#ifndef _SIGNAL_H >>> +#include <signal.h> >>> +#endif >> In practice it's fine to include <signal.h> unconditionally, >> and even multiple times. Have you encountered a version of <signal.h> >> that may not be included twice? If so, it probably deserves a comment >> with the details. > No, I don't have any special condition here. This is probably some past > conditioning resurfacing briefly. If I remember correctly, it had more to do > with compile efficiency rather than avoiding compile failures from multiple > inclusions. Then don't bother. gcc performs a handy optimization whereby it doesn't even open the header file the second (and subsequent) time it's included, as long as it's entire contents is wrapped in the usual sort of guard: #ifndef SYM #define SYM ... #endif

> Index: b/qemud/qemud.c > =================================================================== ... > +static void sig_handler(int sig, siginfo_t * siginfo, > + void* context ATTRIBUTE_UNUSED) { ... > - unsigned char sigc; > + siginfo_t siginfo; > int ret; > > - if (read(server->sigread, &sigc, 1) != 1) { > + if (read(server->sigread, &siginfo, sizeof(siginfo)) != sizeof(siginfo)) { Looks good, but that should be saferead instead of "read". Now that it's reading more than one byte, EINTR can make a difference.

Also, it'd make it a tiny bit easier for people who reply to you if you did not put code after your signature. Or at least not after the "-- " signature-introducer. Some mail clients (at least Gnus) ">"-quote only the part of your message that comes before the signature.