[libvirt] [PATCH] qemu: never send SIGKILL to qemu process unless specifically requested

Eric Blake eblake at redhat.com
Fri Jan 27 21:25:32 UTC 2012


On 01/27/2012 11:35 AM, Laine Stump wrote:
> When libvirt is shutting down the qemu process, it first sends
> SIGTERM, then waits for 1.6 seconds and, if it sees the process still
> there, sends a SIGKILL.
> 
> There have been reports that this behavior can lead to data loss
> because the guest running in qemu doesn't have time to flush it's disk
> cache buffers before it's unceremoniously whacked.

Yeah, SIGKILL can have that effect, and should always be left as a
last-resort option.

> 
> One suggestion on how to solve that problem was to remove SIGKILL from
> the normal virDomainDestroyFlags, but still provide the ability to
> kill qemu with SIGKILL by using a new flag to virDomainDestroyFlags.
> This patch is a quick attempt at that in order to start a
> conversation on the topic.
> 
> So what are your opinions? Is this the right way to solve the problem?
> Any better ideas?

The only thing I worry about is backward incompatibility.  Older clients
are expecting the hard-core whack of the guest, but data loss is never
nice, so I can live with calling this a bug fix and not a backwards
change in behavior.  But if I'm wrong, then we would have to make it so
that the new flag has to be specified if you want to destroy nicely
without a SIGKILL, then call destroy again with flags of 0 if things
aren't responsive enough for you.

At any rate, I like the idea of using a flags value to give the user
control of whether or not to use SIGKILL, and documenting that SIGKILL
should be a last resort.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120127/f04bd993/attachment-0001.sig>


More information about the libvir-list mailing list