Hello, I noticed that during bootup, when the /etc/init.d/slapd script returns, the LDAP server is not fully available. I noticed this because, right after, I have my DHCP server (isc-dhcp-server) starting, and the dhcp configuration configuration is within the local LDAP tree. But, on bootup, dhcp fails to start because it cannot connect to the LDAP server: ----------- dhcpd: Error: Cannot login into ldap server localhost:389: Can't contact LDAP server dhcpd: Configuration file errors encountered -- exiting [...] dhcpd: exiting ----------- Of course, everything works if I just try to start dhcp manually after bootup. It is probably necessary to add in the /etc/init.d/slapd script, either a "sleep 2" or more, either a detection of the "readyness" of the slapd daemon. One could also patch the slapd server, so it could handle this situation itself.--- a/slapd 2012-05-30 04:41:07.000000000 +0200 +++ b/slapd 2012-11-13 15:05:46.194599093 +0100 @@ -146,6 +146,8 @@ start_slapd() { if [ ! -h /var/run/ldapi ] && [ ! -e /var/run/ldapi ] ; then ln -s slapd/ldapi /var/run/ldapi fi + + sleep 2 } # Stop the slapd daemon and capture the error message (if any) to Thank you, Fabien
retitle 696563 slapd not ready when start script exits, please add sleep in starting thanks [re-sending with text wrapping, sorry] Hello, I noticed that during bootup, when the /etc/init.d/slapd script returns, the LDAP server is not fully available. I noticed this because, right after, I have my DHCP server (isc-dhcp-server) starting, and the dhcp configuration configuration is within the local LDAP tree. But, on bootup, dhcp fails to start because it cannot connect to the LDAP server:----------- dhcpd: Error: Cannot login into ldap server localhost:389: Can't contact LDAP server dhcpd: Configuration file errors encountered -- exiting [...] dhcpd: exiting ----------- Of course, everything works if I just try to start dhcp manually after bootup. It is probably necessary to add in the /etc/init.d/slapd script, either a "sleep 2" or more, either a detection of the "readyness" of the slapd daemon. One could also patch the slapd server, so it could handle this situation itself.--- a/slapd 2012-05-30 04:41:07.000000000 +0200 +++ b/slapd 2012-11-13 15:05:46.194599093 +0100 @@ -146,6 +146,8 @@ start_slapd() { if [ ! -h /var/run/ldapi ] && [ ! -e /var/run/ldapi ] ; then ln -s slapd/ldapi /var/run/ldapi fi + + sleep 2 } # Stop the slapd daemon and capture the error message (if any) to Thank you, Fabien
tags 696563 -patch thanks This is absolutely not an acceptable fix for this bug. A 'sleep' only reduces the frequency of a race, it does not eliminate it. We need to find out why the parent slapd process is again exiting before it's ready to listen for connections - this is a regression, for a bug that was very specifically supposed to have been fixed upstream in 2.4.28. See bug #589915 for the history. The source files that were being patched for this haven't changed upstream since 2.4.28, so I'm not sure what will have gone wrong.
Hello, Yes, I totally agree, it would only be a dirty workaround. However, when the issue is complicated to fix, I think that reducing problem frequency in the meanwhile is a good thing, especially when it takes 2 minutes to be done. Then, we can try to find and correct the *source* of the problem, fixing it and remove the ugly workaround. Still better than discussing a long time about how and why it went wrong while everyone still uses "quite frequently" buggy software, IMHO. According to what you say, Squeeze should never have had this issue. Did anyone check if the fix on 2.4.28 was ever really efficient? Also, I'm not sure if this is relevant, but I don't use the Squeeze provided dhcp-server. Yet the init scripts sequence starts it after slapd in the boot dependency order (S02 slapd, S03dhcp if I remember well). Fabien
Please don't get suckered in to this form of thinking. I have a proprietary service at work that takes > 20 minutes to start up, on a redhat system. It's Java based, and has several different processes that it starts up. It's solution for process interdependencies is to sleep 60 seconds, or 300 seconds, or X seconds before starting the next process. Every release seems to get a slower startup time too. I suspect the developers have found corner cases and received support calls where some system condition caused something to not get started within that expected sleep window, and they just increase the sleep time. I have a gripe with systems that don't handle ldap server (or networking) failure properly, and require a restart of that process in the event an ldap connection times out. Bind is also at fault here for not taking such conditions into account.
--On Saturday, December 22, 2012 3:54 PM -0800 Steve Langasek <vorlon@debian.org> wrote: I suggest reading followup #2 in <http://www.openldap.org/its/index.cgi/?findid=6848>, the upstream ITS dealing with this. It is specifically noted that on a heavily loaded system, this can still occur. The real solution is to switch to back-mdb from back-bdb/hdb, which doesn't have the heavy startup load that BDB based backends do.
Hello, --------------- This is still by far the best solution. [...] --------------- Maybe we could try this? - does it *guarantee* any result? - is it a good idea to restrict the user within this kind of choice? Fabien
<sigh> No, the *real* solution is to have a properly sequenced daemon startup. 1) listen on the sockets 2) exit the parent process, detaching from the terminal 3) properly handle all connections made after 2) This is Daemon Design 101. Why is slapd *not* starting the listener thread before detaching? Am I missing some reason this is a problem? Of course, improving slapd's overall efficiency is a good thing, but a faster startup time here only masks the bug, it doesn't eliminate it.