jzeleny@redhat.com wrote:
Full_Name: Jan Zeleny Version: 2.4.23 OS: Linux URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 Submission from: (NULL) (209.132.186.34)
When running slapd listening on local socket (ldapi:///), clients connecting to it will sometimes SIGPIPE when using TLS. This happens in about 70% times.
How to reproduce: generate a pem certificate slapd -h ldapi:/// ldapsearch -H ldapi:/// -ZZ -x -d -1
I'm attaching straces from both slapd and ldapsearch. What seems to be happening is that slapd receives EAGAIN during the read from socket, marks it for another read, but then terminates a reading thread and closes the connection, while client still wants to write some data. When doing ldapsearch, it does this after result was returned, that's why it can be seen probably only in debugging mode.
The issue was originally reported on 2.3.43, but I successfully reproduced it on newer versions, including 2.4.23. The only exception was Fedora rawhide version (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) doesn't seem to support local sockets at all, so it is not possible to use ldapi with -ZZ any more.
Not sure this is worth investigating, since there's no reason to use TLS on ldapi://, and as you already said, it won't even be possible with the upcoming (rawhide) packages.
I'm attaching straces from both successful and unsuccessful run. For complete information here is URL of relevant redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=564108
In regards to the original report, just leave ssl off in the nss_ldap config. Use the starttls URL extension instead. ldap://host/????starttls