Hello, > This is absolutely not an acceptable fix for this bug. A 'sleep' only > reduces the frequency of a race, it does not eliminate it.
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. > 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. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
