Robbie Honerkamp <[EMAIL PROTECTED]> writes:
> I knew syslog had it's problems- it can drop log entries under load and
> has been the source of security problems in the past. But until last
> week I didn't know just how bad it was.
To be fair, some of this is caused by the fact that qmail is considerably
more verbose in its logging than what syslog really expects (and what
programs like sendmail do).
> In short- you can get away with logging to syslogd on low volume
> servers, but if you want to get the best performance out of your server
> or if you're running high-volume mail services you need to drop syslogd
> and move to multilog.
Unfortunately, multilog still lacks, so far as I can see, the ability to
limit by both space *and* time so that you can create clear reporting
boundaries for log summaries. I'd love to have it roll to a new log after
either one day or the size limit, whichever it hits first. You can fake
this up by having your log summarization script troll through older logs
if the newest saved one doesn't contain everything, but it would be a lot
cleaner for multilog to handle it directly, particularly since it now has
timestamp information stored internally. (I could see the argument that
cyclog didn't know anything about time, but that isn't true of multilog
with the t instruction.)
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
