Greg Hudson wrote:
> One possible criticism is that using syslog on Unix unconditionally
> would not make it easy to interoperate with Dan Bernstein's
> daemontools as John Szakmeister (I think; both mail archives are down
> right now) desired.
Yeah, that was me and as long as --foreground redirects all logging to STDOUT,
I'll be happy.
There was a time when syslogd was not robust under heavy load and log lines
would just be dropped on the floor. I don't know if that is true anymore, but
it is something to consider. Given the general rise in performance of CPU's and
hard drives, I suspect that isn't worth getting too worked up about, but some
sites view logs as vital information that must be preserved at all costs.
My personal dislike of syslog stems from a couple of things:
1) I have to run some other program to rotate logs; sure, many/most Linux
distros include something to do this, but it is so much easier to use multilog
and get fully atomic log rolling and purging of old logs. I don't have to keep
log files around for audit purposes forever, so that is a good thing for me; if
you needed to keep files around longer, it is trivial to set up a !processor
directive within multilog to do something other than just rotate.
2) using syslogd would typically require that the person setting up svnserve
(for example) add system configuration directives for each instance (in the form
of a facility line). In other words, using syslog requires external
configuration changes to be fully functional. OK, I'm fudging a little in that
if you don't make those changes, syslogd will just mix your log lines in with
the unwashed masses of other log lines, but I view that as completely unworkable.
3) syslog uses a "threat" model for log levels, as opposed to a "functional"
model. By this I mean that typically you normally have to set the log level
high enough to capture the information you want and exclude the mass of detail
which isn't important in normal operation. Unfortunately, since they set the
LOG_XXX levels assuming that you were interested in only how _bad_ things are,
not considering that sometimes you might want to log good things.
The reason I dislike this mode of operations is that successful operations would
typically be logged at LOG_NOTICE, but that also means that you have to see all
of the LOG_WARN entries, which are often harmless warnings that the programmer
didn't know what else to do with. There is a very coarse granularity caused by
the way the log levels have been ordered, yet (as Brane pointed out) syslog
levels are too numerous to easily keep track of. I suspect this is one reason
why Apache went with a split between error and access logs. Again, I'm fudging
a bit since you can add lines to /etc/syslogd.conf to split logs into multiple
files, but the same objections as #2 apply here.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 20 23:06:34 2005