Re: linux-kernel-digest V1 #123

Theodore Ts'o (tytso@ATHENA.MIT.EDU)
Mon, 24 Jul 95 17:42:21 EDT


From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
Date: Sat, 22 Jul 1995 01:40:26 +0200 (MET DST)

I'm not sure what klogd is, my system currently runs only syslogd.
Is there an advantage to getting and running klogd? (I don't have it)
Note that when the disk is dead, processes that are not very active and
suddenly need to do something stand a high chance of failure.
(because they have been swapped out)

There are a few different syslog/klogd packages out there, it sounds
like. I personally prefer the one where the kernel logging functions
are processed by a separate daemon, klogd, and then forwarded on to
syslogd. (This is the klogd written by Dr. Greg Wettstein, and it's the
syslog/klog supplied by the Slackware distribution.)

I know it is against the "do it in user mode" religion, but I really
think that critical error message printing should be done in the kernel,
not in a user process that probably dies with the system.

Well, when you say "klogd -c 8", the kernel actually does print any
kernel messages more sigificant than level 8 --- i.e., all of them. It
will also forward all kernel messages to the klogd user process, so they
can be saved to a log file. But even if the user process can't run
because the scheduler is screwed, when "klogd -c 8" is in effect, the
panic messages will be printed to the console.

Sure all kinds of nice solutions are possible, but why can't we report
device errors back to the user program, as all other operating systems
seem to be able to do?

You are right that I/O device errors should be reflected back to the
user programs. Hanging clearly not the right thing to do.
Unfortunately, it seems to be something which Linux shares in common
with a lot of other Unix systems --- clearly we should be able to do
better.

- Ted