Re: New logging system ideas
Howard Chu <[email protected]> Sun, 18 Jul 2021 13:43:20 +0100
| Newsgroups | gmane.network.openldap.devel |
|---|---|
| Message-ID | <[email protected]> |
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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/