[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Logging practices (and why does it suck in Debian?)

Kenneth Vestergaard Schmidt wrote:

> Before I start this, however, I would really like to know if this is just 
> going to be something I'll do for myself, or if there's anybody else 
> interested in it? Maybe even design it for inclusion in Debian? I personally 
> think this should be done, since the default now sucks (to put it mildly).

Personally I always redo the standard syslog.conf, but I find it can only
be done well if you know what role your machine is going to generally play
ahead of time.  For example on my workstations I remove the uucp, lpr, and
cron entries, because of the programs I traditionaly use those entries
never see enough use to justify seperate log files, I just let them get put
into the syslog.  I also remove the mail logs that are sorted by priority
because a) on my workstations I use nullmailers and hence don't generate
many logs, and b) on my servers I use qmail w/multilogger.  Finally on my
servers I always remove the xconsole dump as X has no place on a secure
server and hence nobody is going to be looking at that pipe anyway.  But
then I can do all this because I already know what kind of logs to expect
during normal usage and I can "budget" for it.  I wouldn't say that my
configuration is going to work for everybody.  Actually the default debian
syslog config is better than many other default configs in that the split
is fairly intuitive.  OTOH there's something to be said for shipping a
lousy a default configuration as it makes people sit down and become more
familiar with the software they are using.

  Syslog and other facility based loggers just generally suck.  Thats not
really Debian's fault and I'm not really sure what you're going to do about
it.  Unfortunately facility based logging has become the standard in Unix,
even though most of the time its not very usefull.  Worse yet syslog just
isn't reliable.  I run syslog-ng on a few machines but its not much better,
though it is an improvement.  I think this is mostly because syslog-ng
tries too hard to be all things to all people in all situations.

  Dan Bernstein's multilog program is the only logger I've seen that offers
various reliability guarentees and actually delivers on them, but it has
some prerequisites for usage that can frequently be difficult to meet.
What I'd really like to see is a facility logger that could collect logs
like traditional syslog but then would let me hand them to something like
multilog to be stored on disk.

Jamie Heilman                   http://audible.transient.net/~jamie/
"We must be born with an intuition of mortality.  Before we know the words
 for it, before we know there are words, out we come bloodied and squalling
 with the knowledge that for all the compasses in the world, there's only
 one direction, and time is its only measure."		-Rosencrantz

Reply to: