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. Regards, Daniel [1] See the equiv libvirt logic for pidfile acquisition in https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virpidfile.c;h=58ab29f77f2cfb8583447112dae77a07446bc627;hb=HEAD#l384 -- |: 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 :|