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 > closed/rotated/reopened. > 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 > function, > so it's possible that we still won't gain back much performance going down > this route. > > Possibly the parameter should include another field for max # of logfiles to > retain, > I haven't really thought about that yet. > > Comments?
