Looks like there's a little bit more work necessary for kqueue support to function correctly.

--Quanah

------------ Forwarded Message ------------ Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li delphij@delphij.net To: Quanah Gibson-Mount quanah@symas.com, Xin LI delphij@gmail.com Cc: d@delphij.net, Pietro Cerutti gahr@gahr.ch, Xin LI delphij@freebsd.org Subject: Re: kqueue in OpenLDAP for FreeBSD

Hi, Quanah,

I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says:

• The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process.

And slapd does have a fork() after the initial kqueue(), which rendered it invalid.

The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start:

diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid = fork1(); #else - pid = fork(); + pid = rfork(RFPROC); #endif switch ( pid ) {

It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail.

I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc.

What do you think?

Cheers, ---------- End Forwarded Message ----------

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com