On Tue, Jan 25, 2011 at 03:51:06PM -0500, Laine Stump wrote: > On 01/25/2011 12:47 PM, Daniel P. Berrange wrote: > >On Tue, Jan 25, 2011 at 04:24:20AM -0500, Laine Stump wrote: > >>If a guest image is saved in compressed format, and the restore fails > >>in some way after the intermediate process used to uncompress the > >>image has been started, but before qemu has been started to hook up to > >>the uncompressor, libvirt will endlessly wait for the uncompressor to > >>finish, but it never will because it's still waiting to have something > >>hooked up to drain its output. > >> > >>The solution is to manually send a SIGTERM to the compressor process > >>before calling waitpid on it (only if the restore has failed, of > >>course). > >Are we leaking a file descriptor here then ? I would think > >it would get EPIPE or EIO or an end-of-file if QEMU didn't > >start up and automatically exit. That we need to kill it > >seems odd (though a worthy extra measure once we're verified > >that all FDs are closed properly). > > Good point. I guess the proper thing to do is first close the fd > that's pointing to the pipe, then do the kill (which will probably > be unnecessary, but as you say a worthy extra measure). > > Do you think it's necessary to do anything this complicated? > > kill(pid, SIGTERM); > (usleep or maybe a waitpid(pid, &childstat, WNOHANG) ?) > if (kill(pid, 0) == 0) > kill(pid, SIGKILL); > > Or is the single SIGTERM sufficient? I reckon closing the FD + SIGTERM is sufficient. GZip isn't sufficiently complicated that it will hang needing SIGKILL Daniel -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list