Ondřej Kuzník wrote:
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.
Yes, that's exactly what https://git.openldap.org/openldap/openldap/-/merge_requests/358 does.
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.
The reason we're discussing rotate functionality is because of a requirement that no other system dependencies are needed. So, we can't just tell people to use logrotate.
Also, freopen() is not async-signal-safe and so isn't legal inside a signal handler. Nor is it clear that freopen() is atomic within a threaded program. As such, you would still need at least a mutex.