[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eduardo Habkost
Subject: Re: [Qemu-devel] [libvirt] [PATCH v6 2/2] vl: fix use of --daemonize with --preconfig
Date: Wed, 13 Jun 2018 11:17:30 -0300
User-agent: Mutt/1.9.2 (2017-12-15)

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.

* More intuitive

* 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
  (is it a real problem?)
* Any initialization error conditions that currently rely on
  error_report()+exit() will be very inconvenient to handle
  (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.

* Less likely to break initialization code and other QMP commands

* 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.

* Less likely to break init code
* Keeps existing code as is

* Less intuitive
* -daemonize becomes useless as synchronization point for monitor
* Would this be useful for anybody, at all?
* We won't be able to change this behavior later

4) Not supporting -preconfig + -daemonize

* Simple to implement.
* Avoids unexpected bugs.
* Saves our time.
* We can change this behavior later.

* People might want us to support it eventually.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]