[Top][All Lists]

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

Re: Hurd logging. (was zalloc panic)

From: Marcus Brinkmann
Subject: Re: Hurd logging. (was zalloc panic)
Date: Sun, 3 Mar 2002 20:28:53 +0100
User-agent: Mutt/1.3.27i

On Fri, Mar 01, 2002 at 05:28:45PM -0700, Jon Arney wrote:
> > You'll have to make sure those pathes are clean.
> Or that the likelihood of following an unclean path is vanishingly 
> small.

I would say that if you recognize a situation that would make all further
writes (to a file, to a socket) trigger another emergency log (or, let's say
there is a significant likelihood for it), it would make sense for the server
to log a message, and then die.

> There is nothing, for example, that says that the log events
> must be posted synchronously.  I is possible to use ring buffers
> and other mechanisms similar to Linux's klog/printk to reduce the
> likelihood of causing problems.  

Well, another thing that would certainly be useful to have is support for
core files.  The crash server works today, we just don't have a sensible
core file format, and a function that dumps such a core file (and another
function that allows gdb to read it back).

> To take an example look at Linux's kernel logging.  Obviously a
> 'printk' inside a file 'write' function is dangerous even in Linux.
> However, the mechanism, while flawed in the general case is still
> useful in a wide variety of special cases.

The good thing is that we can turn down the server in an emergency, while
the rest of the system is hopefully still up and running, and can at least
attempt a sane shutdown (this is what init does when it sees the death of a
critical system server).  That's why I think that logging once and then
dieing is more useful than logging recursively (and eventual die, with the
disk being full or something).

> > I disagree with our
> > earlier analysis that for example EINVAL from the auth server is unhelpful,
> Yes, perhaps this was an ill-conceived example.

Well, I was just asking myself where we could take best advantage of such
log messages, and noticed that this particular place would not be one, and
thought I was mentioning it.  No fundamental flaw here :)


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]