Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards
Subject: Re: syslog + chroot + ftpd
Message-ID: <18210:Aug103:35:0890@kramden.acf.nyu.edu>
Date: 1 Aug 90 03:35:08 GMT
References: <1990Jul29.202447.11548@athena.mit.edu> <11477:Jul3018:50:4290@kramden.acf.nyu.edu> <1990Jul31.141746.27004@athena.mit.edu>
Distribution: usa
Organization: IR
Lines: 57

In article <1990Jul31.141746.27004@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
> 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.

Yup. (Wow, what a revolutionary idea.)

Let me make three general points first, then address your objections in
their light.

A. A program may invoke a pipe or otherwise avoid stderr if it wants.
B. Multiple processes may send output into one pipe.
C. Pipes are as little work for the system as named UNIX-domain sockets.

> 1. It requires an extra process running for every daemon that's going to spit
>    out errors.

No. See B and C. If you want, you can set up named pipes or sockets
/dev/log*, each feeding into a different type of error processor; as
this special case of my ``proposal'' is a generalization of what syslog
does, your efficiency argument is silly.

> 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.

Yes. Daemons don't use stderr anyway. (See below for further discussion.)

> 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. 

Ever heard of shell scripts? And see A.

> 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.

The reason that such programs *need* two error streams is security. su
should be logging directly to a file, not to a separate daemon that's
easy to clog with spurious messages. See A.

> 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.

That's really dumb. ``stdin and stdout are controlled by the user. Hence
programs must not read input or produce output.'' Obviously when there's
a security issue the program should be writing directly to files. In
other cases, the user is supposed to be in control. Also see A.

---Dan