On 27/11/2017 14:44, Michal Privoznik wrote: > On 11/27/2017 12:09 PM, Paolo Bonzini wrote: >> On 24/11/2017 19:13, Michal Privoznik wrote: >>> On 11/24/2017 06:18 PM, Paolo Bonzini wrote: >>>> On 24/11/2017 18:07, Michal Privoznik wrote: >>>>> The helper is going to be daemonized (for the same reason >>>>> that qemu process is) => there's no SIGCHLD for libvirtd to receive. >>>> >>>> Couldn't (or shouldn't!) libvirt register itself as a subreaper instead? >>> >>> Whether libvirt can't have a >>> separate thread where nothing waitpid() would run? That could hardly >>> work - not only would libvirt need to spawn separate thread for every >>> helper, it would not work across restarts of libvirtd. We would have no >>> guarantee that PID we recorded is still the same process as it was when >>> we were dying. >> >> Oh, you're right. :( Even if libvirtd were a subreaper (see prctl(2) >> manpage), the daemonized qemu-pr-helper would be reparented to init when >> libvirtd restarts. >> >> libvirtd could test whether the helper is alive by connecting to its >> socket. If that's not enough, I'll add an event. > > Well, connecting and staying connected? Otherwise mere connect followed > by immediate disconnect would work only when libvirtd is starting up and > reconnecting to already running domains. Not if the helper dies some > time after libvirt started the domain and the helper. [1] Ok, let's add the event and state command (to QEMU 2.12 only). Thanks, Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
