qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Question about nonblocking stderr and lost logs


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Question about nonblocking stderr and lost logs
Date: Fri, 4 Dec 2015 14:33:01 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Nov 30, 2015 at 04:34:47PM +1100, Sam Bobroff wrote:
> Hi QEMU programmers,
> 
> While doing some experimental work on QEMU that has involved adding a lot of
> new log messages (using qemu_log_mask()), I've discovered that under some
> conditions a lot of my log messages go missing.
> 
> I've tracked the issue down to qemu_logfile being left at the default (stderr)
> (so when not using -D) and according to strace what is happening is that the
> debug messages are being passed to write() but write() is returning 
> EWOULDBLOCK
> and the messags are dropped.
> 
> This seems to be happening because stderr is being set non-blocking (which is 
> a
> bit odd to me), and it seems like NONBLOCK is being set as qmp_chardev_add() 
> adds a
> device for stdout (yes stdout, not stderr; perhaps file descriptors have been
> dup'd by that point?).
> 
> Is this by design to prevent a slow console from blocking QEMU? If not, should
> I delve further and try to prevent non-blocking being set on stderr?
> 
> (Unfortunately I don't have a replication for this using an unmodified QEMU 
> but
> I suspect I could find one if necessary.)

This sounds like a bug.  stderr should be blocking.

But it's specific to your QEMU build or your command-line.  Here are my
results on an x86 host:

$ qemu-system-x86_64 -enable-kvm -m 1024 -cpu host \
                     -drive if=virtio,cache=none,file=test.img,format=raw
$ cat /proc/$(pgrep qemu)/fdinfo/2
pos:    0
flags:  0100002
mnt_id: 22

The flags are O_RDWR | O_LARGEFILE.

O_NONBLOCK would have been 04000 (octal).

Please retry with qemu.git/master and post your QEMU command-line.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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