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) 2) incomplete daemonization before preconfig main loop ------------------------------------------------------ This means calling exit(0) on the main process before doing the chdir/stderr/etc magic. Pros: * Less likely to break initialization code and other QMP commands Cons: * Not what's expected from a well-behaved daemon. (If we're not daemonizing properly, what's the point of using -daemonize at all?) * More difficult to change behavior later. 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 4) Not supporting -preconfig + -daemonize ----------------------------------------- Pros: * Simple to implement. * Avoids unexpected bugs. * Saves our time. * We can change this behavior later. Cons: * People might want us to support it eventually. I believe the only reasonable options are (1) and (4). -- Eduardo