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(a)delphij.net>
To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com>
Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI
<delphij(a)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>