On 2014/10/2 17:55, Martin Kletzander wrote: > On Tue, Sep 30, 2014 at 10:26:21PM +0200, Guido Günther wrote: >> On Tue, Sep 30, 2014 at 04:47:14PM +0200, Martin Kletzander wrote: >>> On Tue, Sep 30, 2014 at 05:34:54PM +0800, Wang Yufei wrote: >>> >Hi, all >>> > >>> >I started and stopped libvirtd service repeatly with high frequency(1 per second), and found that the file capabilities.pidfile is left behind, as well as a qemu process. If I then restart libvirtd, qemu-kvm will fail to start as it's unable to flock capabilities.pidfile's fd. >>> > >>> >>> Have you tried current master? Or at least -rc2? It should already >>> be fixed there: >>> >>> commit 9e159b521dbf18c6da6976e54e29c8553f831eb6 >>> Author: Guido Günther <agx@xxxxxxxxxxx> >>> Date: Thu Sep 25 10:30:58 2014 +0200 >>> >>> qemu: remove capabilities.monitor.sock when done >>> >> >> This one removes the monitor socket, not the pidfile since I didn't >> see that one lingering around in my tests. >> Cheers, > > Oh, sorry for that, my fault. Well, should the daemon just kill the > process when it's dying in order to release the lock? If you try > slower, we will properly remove the pidfile, won't we? Yes, the pidfile will be keep open and locked forever if this qemu process is alive. And it will be unlink if I shutdown libvitd daemon slower. But in this condition(started and stopped libvirtd service repeatly with high frequency) the pidfile is left behind. In fact libvirtd daemon is killed before qemu-kvm process and pidfile are cleaned up. Is it a problem? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list