[libvirt] [PATCH 3/3] Manually kill gzip if restore fails before starting qemu

Daniel P. Berrange berrange at redhat.com
Wed Jan 26 12:12:49 UTC 2011


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




More information about the libvir-list mailing list