not using syslogd in the first place

[Jonathan I. Kamens]

  I'm not going to reply point-by-point to your message, because I have to get
ready to leave town tomorrow, and because frankly, I'm tired of the whole
discussion.

  However, I just want to say that I think it is possible for us to reach an
agreement on this; I won't be around to see whether you agree since (as I
said) I'm leaving towm tomorrow, so if you want to talk to me more about it,
we'll have to do it in E-mail.

  You have listed a number of deficiencies in the syslog() mechanism.  I
agree.  Syslog is broken in many ways.  I agree with you that that brokenness
introduces problems which certainly need to be addressed.

  As I look back over this conversation, I see where I said, "This is how you
fix syslog," and where you responded with, "Well, sending programs to stderr
to a program that deals with them would be more appropriate."  I said, "What,
you mean an extra process running for every daemon running?" and you said,
"Well, just have them all connect to one named pipe so that there's only one
process running, or have different pipes for different sorts of error handling
facilities."  I said, "What, programs can't write to stderr and log errors?"
and you said, "Well, programs that need to write errors to stderr can do that
and log their other errors directly to a file."  I said, "We'll have to
redirect stderr when starting every program," you said, "Just have every
program go to /dev/log by defualt."  I said, "If programs log to a file, then
there's no way for me to get those logging messages on another machine," you
said, "Well, why can't it log to the network as well?"  I said, "Well, you
have to configure each program separately for how it does logging," and you
said, "Well, you can use a central configuration file."

  Frankly, it seems to me that as I offered more and more objections, the
responses from you described more and more closely one thing -- syslogd. 
There's /dev/log for programs to get in touch with the logging program. 
There's a central configuration file.  There's one process logging errors for
multiple daemons.  There's network logging and local logging.

  I don't think you're proposing an alternative to syslogd.  I think you're
proposing an *enhanced* syslogd with the problems in syslogd fixed, new
features added to the daemon, and the library interface between syslogd and C
programs enhanced to make those new features available to programmers.

  Perhaps you don't see the difference, but I do.  To say, "Syslogd is
brain-damaged, let's throw it out completely because whoever wrote it must
have been on LSD," is one thing.  To say, "There are problems with syslogd,
let's fix them," is quite another.

  Frankly, if I was going to reimplement things from scratch, I'd use a
Mach-like philosophy -- establish a default error-handling port in a top-level
process (e.g. init) so that all processes subsequently created inherit that
port, and processes that want to change their error-handler can do so, while
processes that don't can use the default one.  Where the port goes, and what
happens at the other end, are transparent to the programmer -- he just knows
what messages he's allowed to send to the port.  If the protocol is defined
properly, it will be extensible so that people can add things without breaking
what's there already.  Of course, there'll have to be an unspoofable way for a
process to say, "I want the default error port back, no matter what's there
now," so that I can't do things like write my own shell that changes the error
handler and then run su from it so that you never see the errors.

  One of the biggest advantages of doing this way is that programs don't have
to "connect" to the error handler by opening /dev/log or anything like that;
it's already there.  Furthermore, you don't need any shell scripts to redirect
/dev/log.

  Of course, to do things this way, we would need everybody running Mach :-). 
In the mean time, I guess the next best thing is to have everyone agree to
rendezvous at a socket or something and treat that as the error-handling port.
Sort of like syslog, no?

  Now, this sounds a lot like the "error-handling" port is "stderr", but no,
that's not what I mean.  I still maintain that stderr has a very specific
purpose -- the transmission of errors to the USER, or to where the USER wants
them to go.  I think there has to be a difference between where user errors go
and where logging errors go.  If that's our only disagreement, perhaps we can
agree to disagree :-).

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710