On Wed, Jul 14, 2021 at 03:40:35PM +0100, Howard Chu wrote:
Howard Chu wrote:
> Just some initial thoughts on what a new logging daemon should do for us:
Scaling back to something easier for now:
We'll use the existing Debug msgs as-is. The olcLogFile directive will specify the
path of a local logging file to write to. Currently, writing to this logfile is
controlled by the -d debuglevel flags, not the -s sysloglevel flags. When a logfile
is configured, debug messages go to both stderr and the logfile.
We'll add a new option olcLogFileOnly (boolean), which will force messages to only
go to the logfile (and skip writing any to stderr). Since the point of using the
local file logging facility is for performance, it will be desirable to avoid this
double-writing of messages.
We'll add an olcLogFileRotate option that specifies a logfile maxsize and rotation
interval, in megabytes and hours, respectively. Any message that would cause the
current logfile to exceed the specified size will cause the file to be
Any message that arrives after the specified number of hours will do likewise.
Rotated files will be renamed to <logfile>.YYYYMMDDHHMM.
This sounds too complicated, you'd need to measure time and/or size
written everywhere and all the time.
Solutions already exist that do this and everyone knows how to use them:
logrotate(8). We just need to register a signal (SIGHUP or SIGUSR1 are
used most often) and freopen(3) the stderr stream in the handler. No
locks needed, job done.
> Supporting this rotation functionality will require a mutex around the logger
> so it's possible that we still won't gain back much performance going down
> Possibly the parameter should include another field for max # of logfiles to retain,
> I haven't really thought about that yet.