Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: comp.unix.wizards Subject: Re: not using syslogd in the first place Message-ID: <1990Aug1.231821.12226@athena.mit.edu> Date: 1 Aug 90 23:18:21 GMT References: <1990Jul31.141746.27004@athena.mit.edu> <18210:Aug103:35:0890@kramden.acf.nyu.edu> <1990Aug1.052525.22007@athena.mit.edu> <4559:Aug121:33:5590@kramden.acf.nyu.edu> Sender: daemon@athena.mit.edu (Mr Background) Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Distribution: usa Organization: Massachusetts Institute of Technology Lines: 80 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@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710