On Fri, Feb 09, 2018 at 07:12:59PM +0000, Shaun Reitan wrote:
> QEMU leaves the pidfile behind on a clean exit when using the option
> -pidfile /var/run/qemu.pid.
> Should QEMU leave it behind or should it clean up after itself?
> I'm willing to take a crack at a patch to fix the issue, but before I do, I
> want to make sure that leaving the pidfile behind was not intentional?

If QEMU deletes the pidfile on exit then, with the current pidfile
acquisition logic, there's a race condition possible:

To acquire we do

 1. fd = open()
 2. lockf(fd)

If the first QEMU that currently owns the pidfile unlinks in, while
a second qemu is in betweeen steps 1 & 2, the second QEMU will
acquire the pidfile successfully (which is fine) but the pidfile
is now unlinked. This is not fine, because a 3rd qemu can now come
and try to acquire the pidfile (by creating a new one) and succeed,
despite the second qemu still owning the (now unlinked) pidfile.

It is possible to deal with this race by making qemu_create_pidfile
more intelligent [1]. It would have todo

  1. fd = open(filename)
  2. fstat(fd)
  3. lockf(fd)
  4. stat(filename)

It must then compare the results of 2 + 4 to ensure the pidfile it
acquired is the same as the one on disk. With this change, it would
be safe for QEMU to delete the pidfile on exit.


[1] See the equiv libvirt logic for pidfile acquisition in
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Reply via email to