Re: [libvirt] [Qemu-devel] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig

On Tue, Jun 12, 2018 at 01:50:33PM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 12, 2018 at 02:42:05PM +0200, Igor Mammedov wrote: > > We can keep daemonizing flow in QEMU as it's now. > > But Eduardo's idea about libvirt created socked + letting QEMU connect to it > > has a merit. It should fix current deadlock issue with as monitor > > won't be depending on lead exit event. > > NB, libvirt only ever uses --daemonize when probing capabilities, never > when launching QEMU for a real VM. In the latter case, we now use FD > passing, so libvirt opens the UNIX domain socket listener, and passes > this into QEMU. So libvirt knows it can connect to the listener > immediately and will only ever get a failure if QEMU has exited. So, what I'm really missing here is: do we have a good reason to support --daemonize + --preconfig today?

The options I see are: 1) complete daemonization before preconfig main loop ---------------------------------------------------- By "complete daemonization" I mean doing chdir("/"), stderr/stdout cleanup, chroot, and UID magic before calling exit(0) on the main QEMU process. Pros: * More intuitive Cons: * Can break existing initialization code that don't expect this to happen. (can this be fixed?) * Can break any preconfig-time QMP commands that rely on opening files (is it a real problem?)

* Any initialization error conditions that currently rely on error_report()+exit() will be very inconvenient to handle properly (this can be fixed eventually, but it's not trivial)

3) daemonize only after leaving preconfig state ----------------------------------------------- AFAICS, this is the current behavior. Pros: * Less likely to break init code * Keeps existing code as is Cons: * Less intuitive * -daemonize becomes useless as synchronization point for monitor availability

* Would this be useful for anybody, at all? * We won't be able to change this behavior later

I believe the only reasonable options are (1) and (4).