Re: On the stability of TAP tests for LDAP

On Fri, Jul 19, 2019 at 3:30 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> # Running: /usr/sbin/slapd -f
> /home/bf/bfr/root/HEAD/pgsql.build/src/test/ldap/tmp_check/slapd.conf
> -h ldap://localhost:55306 ldaps://localhost:55307
> # loading LDAP data
> # Running: ldapadd -x -y
> /home/bf/bfr/root/HEAD/pgsql.build/src/test/ldap/tmp_check/ldappassword
> -f authdata.ldif
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
> And FWIW, when running a parallel check-world to make my laptop busy
> enough, it is rather usual to face failures with this test, which is
> annoying. Shouldn't we have at least a number of retries with
> intermediate sleeps for the commands run in 001_auth.pl? As far as I
> recall, I think that we can run into failures when calling ldapadd and
> ldappasswd.

Yeah, it seems we need to figure out a way to wait for it to be ready
to accept connections. I wondered how other people do this, and found
one example that polls for the .pid file:

https://github.com/tiredofit/docker-openldap/blob/master/install/etc/cont-init.d/10-openldap#L347

That looks nice and tidy but I'm not sure it can be trusted, given
that OpenLDAP's own tests poll a trivial ldapsearch (also based on a
cursory glance at slapd/main.c which appears to write the .pid file a
bit too early, though I may have misread):

https://github.com/openldap/openldap/blob/master/tests/scripts/test039-glue-ldap-concurrency#L59

I guess we should do that too. I don't know how to write Perl but I'll try...

--
Thomas Munro
https://enterprisedb.com