Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!usc!snorkelwacker!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: syslog + chroot + ftpd
Message-ID: <1990Jul31.141746.27004@athena.mit.edu>
Date: 31 Jul 90 14:17:46 GMT
References: <LUIS.90Jul27181155@lutetia.rice.edu> <1990Jul29.202447.11548@athena.mit.edu> <11477:Jul3018:50:4290@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: 48

In article <11477:Jul3018:50:4290@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
|> Now you're making unsupported assertions. In what conceivable way can
|> syslog() do better than stderr?

  You seem to be suggesting that all programs output errors to stderr, and
daemons that need to do some sort of logging have their stderr piped through a
program that knows how to process those error messages.

  There are a few things right off the top of my head that I see wrong with
this scheme:

1. It requires an extra process running for every daemon that's going to spit
   out errors.  Maybe that's no big deal for you, but my workstation has
   enough daemons running in the background right now, without an extra one
   tacked on for every daemon I'm running now.

2. It eliminates one channel of communication between the program and the
   outside world.  Currently, daemons have stdout, stderr, and syslog().  You
   propose to reduce them to stdout and stderr.

3. Under your scheme, every time I start up a process that I want to log
   messages, I have to pipe its stderr though this logging process of yours. 
   I often start up processes of this sort from the shell, e.g. if I'm
   restarting named after changing one of its config files.  To be honest, I
   don't want to be bothered remembering to do "(named > /dev/null) |&
   /usr/bin/logerrors" (yes, I use csh :-) every time I start it, rather than
   just doing "named" and knowing that it's smart enough to know how to get
   its logging messages to where they belong.

4. There are some programs that run interactively that need to be able to
   both output errors to stderr to the users and to log messages in the system
   logs.  For example, su.  How would su print error messages if it couldn't
   use stderr because it was piped through an error logging program.
   Furthermore, are you going to require users to type "su | logerrors" just
   to make sure that their su attempts get logged?  And, of course, if they
   *don't* type that, does that mean they can su without it getting logged
   anywhere?

5. To generalize (3) and (4) above, the syslog() mechanism is controlled by
   the system.  Stdin, stdout and stderr are controlled by the user.  There
   has to be a way for programs to log things in a way that is guaranteed to
   get them logged (as long as the syslogd is running, of course, and it
   should be running all the time), no matter where stderr points.

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