https://bugs.openldap.org/show_bug.cgi?id=9847
--- Comment #5 from Howard Chu hyc@openldap.org --- (In reply to stu from comment #3)
Tracked it down.
Parent opens kqueue as fd 5. Post fork, child closes fd 5 because
/* a kqueue fd obtained before a fork can't be used in child process.
- close it and reacquire it.
It doesn't work quite like that in OpenBSD. From https://man.openbsd.org/kqueue
kqueue() creates a new kernel event queue and returns a descriptor. The queue is not inherited by a child created with fork(2). Similarly, kqueues ^^^^^^^^^^^^^ cannot be passed across UNIX-domain sockets.
So in the slapd child fd 5 is lock.db and that is what gets closed by SLAP_SOCK_INIT2.
me_lfd remains set to 5 and that is why we get an fcntl later; it is from mdb_reader_pid.
If I remove close() from the macro I no longer hit the problem.
Interesting. The Apple manpage has the same text, but the behavior is different. The *descriptor* is inherited, it just doesn't have any validity as a queue. Since the manpage doesn't say the *descriptor* is not inherited, this sounds to me like an OS bug either in their kernel or their manpage.