Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: savecore can't dump



At Sat, 20 Jun 2009 14:46:16 -0400, Thor Lancelot Simon 
<tls%rek.tjls.com@localhost> wrote:
Subject: Re: savecore can't dump
> 
> *Ahem* let me clear my throat:
> 
>       * /dev/ksyms is now mandatory if you want kvm tools to work in
>         their default configurations
> 
>       * libkvm and its clients can get anything from /dev/ksyms they
>         could get from the kernel executable
> 
>       * Any case where that's not so is a bug and should be fixed.

Not knowing the name of the booted kernel is, or would be, a bug.

Although larger-memory machines can make it somewhat more difficult
and/or time consuming to copy crash dumps off the machine where they
were taken, that's still something I would normally want to do -- my
source code, development environment, and (debugging) tools are all on
one development system, and not (necessarily) on any production machine
I'm responsible for diagnosing problems on.

So, while I agree it is for _some_ intents and purposes a requirement
that the same (or very similar) kernel which crashed be rebooted in
order to properly and safely run "savecore", I must point out that I and
perhaps others won't necessarily be doing anything with the resulting
dump file on the machine where it was created.  I still need to be able
to reliably identify the kernel binary (and all the relevant modules,
iff it is a modular kernel) in order to be able to obtain copies of
those to take as well.  Having savecore do this copying of the kernel
binary at the time the core dump is saved would seem the most ideal and
fail-safe method -- after all it's not often going to be the developer
taking away the dump and kernel copies either as that will be the job of
the local system operator.

So, /dev/ksyms is all well and good and awesome even for _runtime_
diagnostics and monitoring, but it is often absolutely useless for crash
dumps.  Please everyone keep that in mind!

Even for some runtime manual diagnoses and operational concerns it is
often _critical_ for the system manager and/or operator to be able to
tell, after the fact, which kernel was booted to run the current system.
For example if I have to reboot a system that I don't normally operate
on a day-to-day basis then I need to know for certain how it was booted
the last time (either to reproduce it exactly, or to explicitly not
reproduce it if the problem was that it was incorrectly booted last
time).  Even if I'm just trying to identify which kernel to rebuild for
a given production system then I need to be able to identify which it is
actually using.

There are so many conveniences in NetBSD for developers, but all too
often they are at the expense of conveniences for operators.  This
/dev/ksyms feature is of course intended to be good for both, but if it
causes other features to be discarded then it will not be as good as it
should be.  Of course not knowing the booted kernel's name at runtime
from userland isn't necessarily NetBSD's fault -- all too often we're
held back by stupid or misguided or ancient firmware support in less
than ideal underlying platforms.

-- 
                                                Greg A. Woods
                                                Planix, Inc.

<woods%planix.com@localhost>       +1 416 218-0099        http://www.planix.com/

Attachment: pgpatrYeqiEXb.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index