From mboxrd@z Thu Jan 1 00:00:00 1970 From: aq Subject: Re: console problem Date: Sat, 6 Aug 2005 14:37:41 +0900 Message-ID: <9cde8bff0508052237798c45d3@mail.gmail.com> References: <1123274121.3703.22.camel@localhost.localdomain> <42F3CE4A.4080605@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <42F3CE4A.4080605@us.ibm.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: "Li, Xin B" , xen-devel@lists.xensource.com, Stefan Berger , David F Barrera , Li Ge , xen-devel-bounces@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 8/6/05, Anthony Liguori wrote: > Yes, I'm aware of this. The problem is that we've never had a good > dependency system for the daemons we started. The extra daemon has made > the problem much worse and now we're seeing timing issues. >=20 > You can work around the problem by manually starting consoled (you may > have to restart xenstored too). Under the right circumstances, xend > restart will loop because xenstored gets itself hosed. >=20 > I'm reworking a lot of this code right now to make it more robust and > solve the problem completely. Just hang in there a bit :-) as you are rewriting consoled, how about renaming it (for ex, to xenconsole= d) ?=20 now we have xenblkd, xend, xenstored, so if all the xen-related processes have xen as prefix (which is a good thing), we can see what is running by just one command "ps|grep xen" :-) regards, aq