[libvirt] [Question] capabilities.pidfile is left behind while starting and stopping libvirtd repeatly

Wang Rui moon.wangrui at huawei.com
Wed Oct 8 08:07:33 UTC 2014


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 at 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?





More information about the libvir-list mailing list