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(a)sigxcpu.org>
>> 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?