From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: That xenstored console leak... Date: Fri, 11 Jan 2008 12:48:20 -0700 Message-ID: <4787C804.4010909@novell.com> References: <20080111173914.GA24773@totally.trollied.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080111173914.GA24773@totally.trollied.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: John Levon Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org John Levon wrote: > Here's what I'm using to fix it in 3.1. Obviously too risky for 3.2 now, > and anyway, there's a much more serious problem in 3.2 - entire /vm/ > entries are leaked on domU reboot! I haven't got round to debugging that > one yet since it's not present in 3.1, but it really should be fixed > I'm unable to reproduce the console leak on 3.2. I have tried rebooting managed PV domU's several times with no orphaned console entries - using 'xm reboot' and rebooting within the guest itself. I do however see the entire /vm/ nodes leaking and agree that this is a rather serious bug as it could eventually cause swap thrashing in dom0 [1]. E.g. after 3 reboots of PV domU xenstore contains vm faa7647e-142b-74c7-dc72-efd57fe6d0ef-1 = "" image = "(linux (kernel ) (args 'mem=512M ') (device_model /usr/lib64/xen/bin/qemu\..." ostype = "linux" ... faa7647e-142b-74c7-dc72-efd57fe6d0ef = "" image = "(linux (kernel ) (args 'mem=512M ') (device_model /usr/lib64/xen/bin/qemu\..." ostype = "linux" ... faa7647e-142b-74c7-dc72-efd57fe6d0ef-2 = "" image = "(linux (kernel ) (args 'mem=512M ') (device_model /usr/lib64/xen/bin/qemu\..." ostype = "linux" ... This leak is much worse than a single device leaking :-(. I'll have a look but may be a day or two before I can get to it. Jim [1] http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00641.html