Michal Privoznik <mprivozn(a)redhat.com> [2018-09-19, 11:45AM +0200]:
On 09/19/2018 11:17 AM, Bjoern Walk wrote:
> Bjoern Walk <bwalk(a)linux.ibm.com> [2018-09-12, 01:17PM +0200]:
>> Michal Privoznik <mprivozn(a)redhat.com> [2018-09-12, 11:32AM +0200]:
>>
>
> Still seeing the same timeout. Is this expected behaviour?
>
Nope. I wonder if something has locked the path and forgot to unlock it
(however, virtlockd should have unlocked all the paths owned by PID on
connection close), or something is still holding the lock and connection
opened.
Can you see the timeout even when you turn off the selinux driver
(security_driver="none' in qemu.conf)? I tried to reproduce the issue
yesterday and was unsuccessful. Do you have any steps to reproduce?
So, I haven't been able to actually dig into the debugging but we have
been able to reproduce this behaviour on x86 (both with SELinux and
DAC). Looks like a general problem, if a problem at all, because from
what I can see in the code, the 60 seconds timeout is actually intended,
or not? The security manager does try for 60 seconds to acquire the lock
and only then bails out. Why is this?
However, an actual bug is that while the security manager waits for the
lock acquire the whole libvirtd hangs, but from what I understood and
Marc explained to me, this is more of a pathological error in libvirt
behaviour with various domain locks.
--
IBM Systems
Linux on Z & Virtualization Development
--------------------------------------------------
IBM Deutschland Research & Development GmbH
Schönaicher Str. 220, 71032 Böblingen
Phone: +49 7031 16 1819
--------------------------------------------------
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294