Hi, Paolo and Michal:
Let me add some details about this problem.
reappear steps:
1. in Host, execute the following command many times quickly:
"ps aux|grep helper|grep -v grep|grep -v qemu-kvm|awk '{print
$2}';ps aux|grep helper|grep -v grep|grep -v qemu-kvm|awk '{print
$2}'|xargs -n1 kill -9"
2. at the same time , execute PR command continuously in Guest
just execute step 1 and 2 for a moment, the problem will appear.
when the problem appeared:
1. qemu will initialize pr-helper and connect to it cyclically,
but always failed because no running pr-helper process to connect.
2. libvirt will always waiting
for connected event, but will never to start new pr-helper
process because not receive disconnect event.
I'm not found the best way to
solve this problem, can you give me some suggestion?
On 2019/5/29 15:33, Michal Privoznik
wrote:
On
5/28/19 7:45 PM, Paolo Bonzini wrote:
On 28/05/19 15:06, Jie Wang wrote:
if pr-helper been killed and qemu send
disconnect event to libvirt
and libvirt started a new pr-helper process, the new
pr-heleper
been killed again when qemu is connectting to the new
pr-helper,
qemu will never send disconnect to libvirt, and libvirt will
never
receive connected event.
I think this would let a guest "spam" events just by sending a
lot PR
commands. Also, as you said, in this case QEMU has never sent a
"connected" event, so I'm not sure why it should send a
disconnection event.
So pr manager is initialized on the first PR command and not when
qemu is starting?
If a user inside the guest could somehow kill pr-helper process in
the host then yes, they could spam libvirt/qemu. But if a user
from inside a guest can kill a process in the host that is much
bigger problem than spaming libvirt.
Does libvirt monitor at all the pr-helper to check if it dies?
Or does
it rely exclusively on QEMU's events?
Libvirt relies solely on QEMU's events. Just like with qemu
process itself, libvirt can't rely on SIGCHILD because the daemon
might be restarted which would reparent all qemu and pr-helper
processes rendering libvirt wait for SIGCHILD useless.
But there is an exception to this: when libvirt is spawning
pr-helper it does so by following these steps:
1) Try to acquire (lock) pidfile
2) unlink(socket)
3) spawn pr-helper process (this yields child's PID)
4) wait some time until socket is created
5) some follow up work (move child's PID into same cgroup as
qemu's main thread, relabel the socket so that qemu can access it)
If any of these steps fails then child is killed. However, the PID
is not recorded anywhere and thus is forgotten once control jumps
out of the function.
Michal
.