maxime.besson@worteks.com wrote:

Full_Name: Maxime Besson Version: 2.4.48 OS: Debian Buster / CentOS7 URL: https://cloud.worteks.com/index.php/s/9CE6ALLaAfrxZW4/download Submission from: (NULL) (92.184.104.113)

Thanks for the report and testcase, fixed now in git master.

I have two OpenLDAP (2.4.48, Ubuntu) servers running with syncrepl in mirrormode.

One of my server's X509 certificates has recently expired, and I noticed that while it was expired, the other node's connection count kept climbing until it a "Max open files" condition. It seems that when a Syncrepl consumer encounters a certificate error, the outgoing LDAP connection to the provider is never closed.

Attached to this bug you will find a test case to reproduce this behavior

# runs a provider with a bogus certificate 
# and a consumer with retry=3+
sh test.sh 
...
TLS certificate verification: Error, self signed certificate
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in error
TLS: can't connect: error:1416F086:SSL

routines:tls_process_server_certificate:certificate verify failed (self signed certificate). 5e160966 slap_client_connect: URI=ldaps://127.0.1.1:6636/ DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) 5e160966 do_syncrepl: rid=001 rc -1 retrying ... and so on, every 3 seconds

While the consumer retries, running lsof on its PID will reveal the connection leak:

42u     TCP localhost:45964->localhost.lan:6636 (CLOSE_WAIT)
43u     TCP localhost:45966->localhost.lan:6636 (CLOSE_WAIT)
44u     TCP localhost:45968->localhost.lan:6636 (CLOSE_WAIT)
45u     TCP localhost:45970->localhost.lan:6636 (CLOSE_WAIT)
46u     TCP localhost:45972->localhost.lan:6636 (CLOSE_WAIT)
47u     TCP localhost:45974->localhost.lan:6636 (CLOSE_WAIT)
48u     TCP localhost:45976->localhost.lan:6636 (CLOSE_WAIT)
49u     TCP localhost:45978->localhost.lan:6636 (CLOSE_WAIT)
50u     TCP localhost:45980->localhost.lan:6636 (CLOSE_WAIT)
51u     TCP localhost:45982->localhost.lan:6636 (CLOSE_WAIT)
52u     TCP localhost:45984->localhost.lan:6636 (CLOSE_WAIT)
53u     TCP localhost:45986->localhost.lan:6636 (CLOSE_WAIT)
54u     TCP localhost:45988->localhost.lan:6636 (CLOSE_WAIT)
55u     TCP localhost:45990->localhost.lan:6636 (CLOSE_WAIT)
56u     TCP localhost:45992->localhost.lan:6636 (CLOSE_WAIT)
57u     TCP localhost:45994->localhost.lan:6636 (CLOSE_WAIT)
58u     TCP localhost:45996->localhost.lan:6636 (CLOSE_WAIT)
59u     TCP localhost:45998->localhost.lan:6636 (CLOSE_WAIT)
60u     TCP localhost:46000->localhost.lan:6636 (CLOSE_WAIT)
61u     TCP localhost:46002->localhost.lan:6636 (CLOSE_WAIT)
62u     TCP localhost:46004->localhost.lan:6636 (CLOSE_WAIT)
63u     TCP localhost:46006->localhost.lan:6636 (CLOSE_WAIT)
64u     TCP localhost:46008->localhost.lan:6636 (CLOSE_WAIT)

Modifying the provider URL in slapd.2.conf with a wrong port causes the syncrepl consumer to fail and retry just as much, but without connection piling up in CLOSE_WAIT state.

This is not a very critical issue because it only affects servers who are in already degraded condition (broken replication, invalid certificate on the provider) but I thought it still was worth reporting.

I was able to reproduce this issue on the git master branch, on released 2.4.48, on Centos7 and on Debian Buster. OpenSSL version on the debian system: 1.1.1d-0+deb10u2