[Libvir] [PATCH] lxc: handle SIGCHLD from exiting container

[Daniel P. Berrange]

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 :|