From: Keir Fraser <keir@xen.org>
To: Mark van Dijk <lists+xen@internecto.net>, xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: Possible bug with huge unflushed console buffer
Date: Wed, 08 Aug 2012 17:42:23 +0100 [thread overview]
Message-ID: <CC48557F.484FE%keir@xen.org> (raw)
In-Reply-To: <20120808174355.470746e0@internecto.net>
On 08/08/2012 16:43, "Mark van Dijk" <lists+xen@internecto.net> wrote:
> Greetings list,
>
> Yesterday the following scenario took place. In short, I had a HVM host
> with a poorly configured firewall. It logged way more than it should,
> and it had been doing that for days. IPTables entries with -j LOG
> show up in the console. I told Konrad about this but I said it was a PV
> host while in fact it is concerning a HVM host.
>
> Anyway, when I saw that this was the case I corrected iptables and then
> I removed those faulty log entries from the logfiles in /var/log.
> Finally I issued /etc/init.d/rsyslogd reload.
>
> Suddenly the server stopped responding at all, not even arp requests
> were answered. I opened up a console via xl (none was open before
> this) and I was greeted with a crazy amount of log entries - it took
> about five or six minutes before the whole buffer was flushed to my
> screen. Then the server responded again.
>
> Today I viewed syslog's messages in detail and found this and a lot of
> similar entries:
>
> http://pastebin.com/Ga7aE7hb
>
> So the questions that I have now are - Is this a bug? How is console
> history handled and where is the console's unread history stored?
> Somewhere in the hypervisor or in dom0 or domU memory space? Is there a
> limit to how much info can be stored?
>
> The behaviour I encountered i.e. a system lock seems to suggest that
> there was some kind of buffer overflow. And this can be achieved by
> something as simple as 'iptables -I INPUT -j LOG'. Perhaps it is a wise
> idea to consider xl console -c to clear the console's history, then at
> least I could exit the console and clear unsent messages...
Is your VM logging to its virtual serial line? You could just not do that...
I think this is due to the guest's qemu-dm process stuffing its transmitted
serial data into a pty, to be consumed by 'xl console', and if that doesn't
happen the buffers fill up, serial processing stops, and we back up all the
way to the guest.
-- Keir
> I am not receiving xen-devel messages, so please CC me on replies.
> Thank you.
next prev parent reply other threads:[~2012-08-08 16:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 15:43 Possible bug with huge unflushed console buffer Mark van Dijk
2012-08-08 16:42 ` Keir Fraser [this message]
2012-08-10 9:29 ` Mark van Dijk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CC48557F.484FE%keir@xen.org \
--to=keir@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=lists+xen@internecto.net \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).