On Tue, Mar 01, 2016 at 12:15:21PM +0100, Gerd Hoffmann wrote:
> On Do, 2016-02-18 at 13:38 +0200, Dimitris Aragiorgis wrote:
> > In case of daemonize, use the logfile passed with the -D option in
> > order to redirect stderr to it instead of /dev/null.
> >
> > Also remove some unused code in log.h.
>
> Patch breaks interaction with libvirt. libvirt hangs on startup, while
> probing qemu capabilities. qemu runs in probing mode (command line is
> "/home/kraxel/projects/qemu/build-default/x86_64-softmmu/qemu-system-x86_64
> -S -no-user-config -nodefaults -nographic -M none -qmp
> unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile
> /var/lib/libvirt/qemu/capabilities.pidfile -daemonize" according to
> "systemctl status libvirtd -l"), apparently both qemu and libvirt wait for
> each other.
When libvirt is probing capabilities it passes a pipe file descriptor
for stderr. It reads from this pipe to detect any errors printed by
QEMU before daemonizing. When QEMU daemonizes, it closes this FD and
sets stderr to /dev/null. Libvirt knows qemu has successfully started
up at this point.
With this patch though, this code:
@@ -275,7 +276,10 @@ void os_setup_post(void)
dup2(fd, 0);
dup2(fd, 1);
- dup2(fd, 2);
+ /* In case -D is given do not redirect stderr to /dev/null */
+ if (!qemu_logfile) {
+ dup2(fd, 2);
+ }
close(fd);
means that QEMU will never close stderr anymore, so libvirt things
QEMU is still starting up....forever.
Given current libvirt behaviour / expectations, I think the only
option is to revert this change.
IMHO if applications want qemu logs to go to stderr, they should
explicitly ask for that to happen via a CLI arg.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
