All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: James Harper <james.harper@bendigoit.com.au>,
	xen-devel@lists.xensource.com
Subject: Re: domains not shutting down properly - theproblemisback again
Date: Fri, 02 Jan 2009 09:55:49 +0000	[thread overview]
Message-ID: <C5839525.20AB7%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01550170@trantor>

On 02/01/2009 09:11, "James Harper" <james.harper@bendigoit.com.au> wrote:

>> The only thing that seems to make a difference is:
>> 
>> /etc/init.d/xend stop
>> killall xenstored
>> /etc/init.d/xend start
>> 
>> Once I do that, everything works perfectly. Now I guess I just have to
>> try and find out what is different between starting it on a freshly
>> booted system vs restarting it...
> 
> Just to clarify, by 'everything works perfectly' I mean that a domain
> that doesn't have any vif or vbd interfaces (just a 'kernel=' line for
> testing), crashes and cleans up after itself, as opposed to crashing and
> hanging around. Restarting xenstored obviously breaks the connection to
> the Dom0 backend drivers.

Yeah, I was going to say... :-)

Anyway, your observations can be explained by the fact that the restarted
xenstored will not auto-connect to any domain. So since it holds no
resources of the domU, it won't impede the domU's destruction.

Xenstored is supposed to receive a VIRQ_DOM_EXC when a domain is killed (see
xen/common/domain.c:domain_kill(). This should trigger
xenstored_domain.c:domain_cleanup() which queries every domain it knows
about and if it sees XEN_DOMINF_dying (which gets cooked in libxenctrl into
boolean flag dominfo.dying) then it should talloc_free() the domain state
and hence release resources. These are the paths you need to log.

 -- Keir

  reply	other threads:[~2009-01-02  9:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-01 13:03 domains not shutting down properly - the problem is back again James Harper
2009-01-01 13:09 ` domains not shutting down properly - the problem isback again James Harper
2009-01-01 14:08   ` Keir Fraser
2009-01-01 14:34     ` Venefax
2009-01-01 14:41       ` Keir Fraser
2009-01-01 23:52     ` James Harper
2009-01-02  2:38     ` James Harper
2009-01-02  3:40     ` James Harper
2009-01-02  4:15       ` domains not shutting down properly - the problemisback again James Harper
2009-01-02  4:48         ` James Harper
2009-01-02  9:11           ` domains not shutting down properly - theproblemisback again James Harper
2009-01-02  9:55             ` Keir Fraser [this message]
2009-01-02 10:11               ` James Harper
2009-01-02 10:28                 ` Keir Fraser
2009-01-02 10:28               ` James Harper
2009-01-02 10:41                 ` Keir Fraser
2009-01-02 10:48                   ` James Harper
2009-01-02 11:47                     ` domains not shutting down properly - theproblemisbackagain James Harper
2009-01-02 12:34                       ` Keir Fraser
2009-01-02 13:27                         ` domains not shutting down properly -theproblemisbackagain James Harper
2009-01-02 15:31                           ` Keir Fraser
2009-01-03  0:57                             ` James Harper
2009-01-03  2:25                               ` domains not shutting down properly-theproblemisbackagain James Harper
2009-01-03  5:12                             ` domains not shutting down properly -theproblemisbackagain James Harper
2009-01-03  5:36                               ` domains not shutting down properly-theproblemisbackagain James Harper
2009-01-03  6:29                                 ` bug in evtchn_cpu_notify (was domains not shutting down properly-theproblemisbackagain) James Harper
2009-01-03  7:04                                   ` James Harper
2009-01-03  8:52                                     ` Keir Fraser
2009-01-02 12:52                       ` domains not shutting down properly -theproblemisbackagain James Harper
2009-01-02 11:15                   ` domains not shutting down properly - theproblemisback again James Harper

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=C5839525.20AB7%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=james.harper@bendigoit.com.au \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.