asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
hyc(a)symas.com wrote in ITS#8240:
> Our patch response was too hasty. There is no OpenLDAP bug here, the real
> issue is production binaries being built with asserts enabled instead of
> compiling with -DNDEBUG. That's an issue for packagers and distros to resolve.
> Closing this ITS, not an OpenLDAP bug.
Maybe I missed something. But this is the first time I've heard about -DNDEBUG
being mandatory when compiling binary packages for production use. Does it
have other effects?
And what are general rules for assert statements in OpenLDAP code?
In my own (Python) code assert statements are supposed to be only triggered if
something goes wrong *internally* (type issues etc.). If somebody manages to
trigger an assert statement with invalid input from "outside" I always
consider this to be a serious bug revealing insufficient error handling even
though e.g. web2ldap just logs the exception but won't crash. YMMV, but please
clarify.
I also wonder whether there are more mandatory rules for building packages and
where I can find them.
Please don't get me wrong: My inquiry is in good faith to avoid unnecessary
ITS based on misunderstanding.
Ciao, Michael.
1 year, 11 months
About REP_TEXT_MUSTBEFREED (ITS#6138)
by Hallvard Breien Furuseth
REP_TEXT_MUSTBEFREED looks like a bad idea, at lest for now:
Errors can happen anywhere, and then sr_text is usually set
to a string constant. If REP_TEXT_MUSTBEFREED is already set,
slapd will then later try to free that constant.
To add this flag, first add result.c:rs_replace_text() or
something similar, like rs_replace_entry(). Modify all code
which modifies sr_text to use this function/macro, and
encourage 3rd party code to do the same.
Also look at code which copies a SlapReply.
Each REP_*_MUSTBEFREED flag and its related data should be
managed by a similar function/macro, really.
(I tried to add a comment in Github, but that didn't
seem to work, so mailing here instead.)
2 years, 2 months
Re: New logging system ideas
by Howard Chu
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/
2 years, 2 months
New logging system ideas
by Howard Chu
Just some initial thoughts on what a new logging daemon should do for us:
The primary goal - we want to use a binary message format with as few format conversions as possible between log
sender and log processor.
I'm thinking that we use message catalogs; we will need a tool to preprocess every logging
invocation in the source tree and replace them with a integer messageID. So at runtime only
the messageID and the message parameters need to be sent, not any plaintext.
The message catalog will be compiled into the binary. When it performs its "openlog" to talk
to the logging server, it will send the UUID of its catalog. If the logging server doesn't
know this UUID, it will transmit the message catalog to the logging server, before doing
anything else. (It may make more sense just to use a SHA hash here instead of a UUID.)
This way the logging server will work with any version of the binaries, and we don't need
to do special coordination to update message catalogs between revisions. The logging server
will just know that a specific catalog is to be used with a particular logging session.
The message protocol will be length-prefixed. We may even just use DER, since that would
allow us to encode arrays of parameters, and other such stuff.
The logging server will write the log messages to disk/network verbatim, doing no
parsing at all. It may prefix the records with a log session ID, so that a postprocessor
can lookup the catalog that belongs to the session, for dumping out as text.
The logging server can store its received catalogs in an LMDB database. The postprocessor
can then lookup individual messageIDs in this database, interpolate the parameters, and
dump out in text.
... that's what I have so far. It's a bit worrisome because of the additional moving parts:
message catalog creator, log server, log postprocessor. There's definitely more complexity
here, but most of it is moved out of the runtime hot path, which is the main goal. Suggestions?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2 years, 2 months
