[plug] Kernel logs

James Devenish devenish at guild.uwa.edu.au
Tue Oct 28 22:38:08 WST 2003


In message <20031028132837.GC11615 at amidala>
on Tue, Oct 28, 2003 at 09:28:37PM +0800, Bernard Blackham wrote:
> On Tue, Oct 28, 2003 at 03:44:02PM +0800, James Devenish wrote:
> > (2) Logging of Ethernet link information.
> 
> Information such as "up", "down"? This is fairly driver dependent,
> and very few drivers I've seen do.

Though I believe you, though it surprises me because I thought things
would be largely standard (e.g. IEEE + ISO + POSIX). I suppose vendor
documentation is probably a problem (e.g. which registers, bit layout,
magic numbers, op codes, etc.).

> One alternative if you care about your kernel logging in times of
> despair

It seems that dealing with kernel-level fault scenarios is an area
where other operating systems currently have an edge.

> Although this doesn't help if it never gets the chance to write it
> to disk again anyway, but for transient failures, it might help. As
> others have pointed out, remote logging would probably be the go.

I'm probably being parochial, but I don't like the idea of attempting to
transfer cores over a network link as the first priority. While it *is*
lovely to have failure-mode data stored remotely (yay for remote
loghosts, for instance), I do feel some sort of opposition between using
the network and having the best response. I know that Linux will give
people the choice though, so that's great.

This sort of issue is obviously context-dependent, as is a somewhat
related issue: most people probably think it sounds ideal that a reboot
would give you a "fresh slate", but it is actually quite nice to have a
system that does a more mild sort of reboot in the event of failure.
For example: not losing every kernel parameter that hadn't been stored
in /etc/sysctl.conf. I.e. the thing that's better than recovering to a
"fresh slate" is being able to pick up where you left off. Run-of-the-
mill transactional and non-fragile systems are a nice taste of this sort
of thing: kill it, zap it, vomit on it and it'll quickly brush itself off
and carry on in a neat way despite the lack of a redundant twin.


_______________________________________________
plug mailing list
plug at plug.linux.org.au
http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug


More information about the plug mailing list