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 :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
