policies on coredump

policies on coredump

[Kip Macy]

I'm soliciting opinions on where domU coredumps should be put, if they
should be enabled by default, and what the default naming convention
should be. This will probably all have to change when capabilities are
added, but in the meantime I'd like to know before I submit a patch.


 -Kip

Re: policies on coredump

[Mark Williamson]

> I'm soliciting opinions on where domU coredumps should be put,

/var/xen/dump/ perhaps?

> if they 
> should be enabled by default

Hrrrmmmmm.  I guess I'd err towards not enabling them by default - as long as 
we document it (fancy including a patch to the user manual? ;-)).  This is on 
the grounds that people who will use this feature will know who they are and 
go switch it on.

> and what the default naming convention 
> should be.

Howsabout domainname.{0,1,2,3...} ?  The textual domain name will be available 
in Xend and is a bit more useful than the domid, particularly if you're 
running many domains.

> This will probably all have to change when capabilities are 
> added, but in the meantime I'd like to know before I submit a patch.

I don't think capabilities are coming up for a while, though I've not heard 
anything about it recently.  I bet you can get your patch in first anyhow ;-)

Are you planning to hook into Xend's reaper function to do this automatically 
and / or provide an xm command for manual dumps?

Cheers,
Mark

Re: policies on coredump

[Kip Macy]

> Are you planning to hook into Xend's reaper function to do this automatically
> and / or provide an xm command for manual dumps?

If it is in the reap path is there any reason to add it to xm as well
other than testing?

    -Kip

Re: policies on coredump

[Mark Williamson]

> If it is in the reap path is there any reason to add it to xm as well
> other than testing?

I guess that now, for most things, you could use the gdbserver to poke at the 
state of domains that hadn't crashed (and auto-dumped) yet...  Under some 
circumstances it might be useful to manually dump domain state for later 
analysis.

Unless anybody pipes up and asks then I guess it might not be worth adding.  
It's probably worth getting the reap-path patch into the tree in the first 
instance - then other people can contribute patches to enable any use cases 
they want ;-)

Cheers,
Mark

Re: policies on coredump

[Kip Macy]

My plan is for coredump to write out the domain state in a generic
format and then post-process that into the format expected by the
kernel GDB for a given OS. I can envision using the suspend support
for offline state inspection by simply post-processing the output of
suspend to disk into coredump format. I don't see anyone else
clamoring to use xen as a development environment so I'll worry about
that later.

      -Kip
 
On 4/27/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> > If it is in the reap path is there any reason to add it to xm as well
> > other than testing?
> 
> I guess that now, for most things, you could use the gdbserver to poke at the
> state of domains that hadn't crashed (and auto-dumped) yet...  Under some
> circumstances it might be useful to manually dump domain state for later
> analysis.
> 
> Unless anybody pipes up and asks then I guess it might not be worth adding.
> It's probably worth getting the reap-path patch into the tree in the first
> instance - then other people can contribute patches to enable any use cases
> they want ;-)
> 
> Cheers,
> Mark
>