Someone pointed out to me off-list that my proposed architecture, with each syslogging client creating a pipe to a dedicated instance of a vaguely multilog-inspired writer, makes the logfile rotation process vastly harder. Stumped me for a little that did. Then I came up with an idea. Suppose all writers closed and reopened the file they were writing to every N seconds. Say, 3600 default, configurable by envar or comment in syslog.conf or something. Then rotation logic wouldn't be too bad, just cycle the logfiles at any interval greater than N, and hold off compressing for one cycle. I think a timing plus delayed compress constraint on the logfile rotator wouldn't be too excruciating a departure from pure syslog compatibility. It's even a pattern directly supported by logrotate(8), with the delaycompress option. For high-volume dedicated loggers, where one process is the only thing writing to a file and it's doing so at a heroic rate, we could also have the option of multilog-style rotation, where the logging process itself does the rotation every time it hits a configurable size threshhold. -Bennett
This archive was generated by hypermail 2b30 : Sun May 30 2004 - 11:08:28 PDT