https://bugs.openldap.org/show_bug.cgi?id=9847
--- Comment #8 from stu@spacehopper.org --- On 2022/05/14 16:02, openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=9847
--- Comment #6 from Howard Chu hyc@openldap.org ---
this sounds to me like an OS bug either in their kernel or their manpage.
"Their" meaning OpenBSD.
Since you submitted that patch to FreeBSD: did you verify that it is actually misbehaving on FreeBSD first? We've seen no bug reports about it and this support has been in the tree for a couple years already.
-- You are receiving this mail because: You reported the issue.
I didn't submit that to FreeBSD; they have had it since they added OpenLDAP 2.5.x back in Sept 2021.
https://cgit.freebsd.org/ports/commit/net/openldap25-server?id=53fec214c68a5...
That port was committed by Xin Li who has comments forwarded in ITS#6300 where kqueue was added so they presumably already knew about this issue. If the majority of FreeBSD users are using the port (which is quite likely) they would have been insulated from this and not needed to report.
FreeBSD has more precise text in fork(2),
The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not in- herited from the parent process.
Unsurprisingly DragonFlyBSD has the same patch in their port as FreeBSD.
NetBSD does not have a patch like this in pkgsrc but I found a fairly recent list post suggests the child does not (at least as on 2021/09) inherit the kqueue fd on fork - so it's unclear how things are working in there, if indeed things *are* working there. https://mail-index.netbsd.org/netbsd-users/2021/09/30/msg027833.html
It seems the slapd kqueue code was originally donated by Apple so it would make sense that it would primarily target their implementation. (Other things e.g. that it's broken with device nodes does suggest that Apple's kqueue is a bit different to others).