syslog + chroot + ftpd
Jonathan I. Kamens
jik at athena.mit.edu
Wed Aug 1 00:17:46 AEST 1990
In article <11477:Jul3018:50:4290 at kramden.acf.nyu.edu>, brnstnd at 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 at Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8495 Home: 617-782-0710
More information about the Comp.unix.wizards
mailing list