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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
