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)
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