On Wed, Jun 13, 2018 at 11:17:30AM -0300, Eduardo Habkost wrote:
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?
On the libvirt zero, I don't see a compelling need for it.
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?)
NB Use of -chroot is separate from -daemonize, so it is not an issue with -preconfig + -daemonize alone. There's soo many caveats around -chroot, I struggle to care about adding another caveats.
* 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
Yeah that honestly kills the key benefit of having -daemonize imho.
* 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).
Agreed. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|