Many "connection_read(): no connection!" warnings from OpenLDAP server when using ldapi:/// and a bind DN (no external authentication)

[Mark A. Ziesemer]

Reported upstream at http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6548 , but it needs to be re-opened there.

Many "connection_read(): no connection!" warnings are written to /var/log/debug and /var/log/syslog by slapd. As stated at http://www.openldap.org/lists/openldap-software/200811/msg00079.html , this is apparently not a problem with slapd, but a client that is disconnecting without first unbinding.

This appears to be an issue with the libldap client library provided by OpenLDAP itself (2.4.21), and not the slapd daemon.

Issue is reproducible even by just using "ldapsearch -H ldapi:///", but only if a bind DN is specified (-D) and external authentication is not used.

Running slapd with logging enabled (-d 8) shows the attached 3 sequences - ldapsearch command followed by the slapd logs. Note that the "connection_read(): no connection!" is only visible on the middle pair.

If this can't / won't be fixed in the client library, the logging of the "connection_read(): no connection!" event from slapd should at least be demoted to a lower level so that it doesn't fill the default logging output, without having to change the overall configured logging level and potentially missing other logged events that do require attention.

Ubuntu 10.04, libldap-2.4-2 : 2.4.21-0ubuntu5

Also still confirmed in Ubuntu 11.10, libldap-2.4-2 : 2.4.25-1.1ubuntu4.1

[Kjell Braden (afflux)]

I can reproduce this behavior by running "ldapsearch -H ldapi:/// -Y EXTERNAL", too.

This symptom can be shut off with the rsyslog rule, should be at the top of /etc/rsyslog.d/50-default.conf:

--snip--
:msg, contains, ": no connection" ~
--snip--

[Marcio Merlone (mmerlone)]

This affects not just logging, but it seems to affect search capability from some clients. For instance, my thunderbird addressbook fails occasionally. Simultaneously on the client error, I get these error messages on syslog:

slapd[29694]: SASL [conn=1577] Failure: realm changed: authentication aborted
slapd[29694]: connection_read(46): no connection!

This is happening not all times with all users on my network (about 100 users).

[airtonix (airtonix-gmail)]

still occuring

[Mark A. Ziesemer (ziesemer)]

Some interesting comments left in the notes field at http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6548 :

fixed in master
fixed in RE24

So hopefully this means that a fix is pending - eventually?

[Ryan Tandy (rtandy)]

Hi,

as per the upstream changelog ITS#6548/#7092 were fixed upstream in 2.4.27, so Fix Released in precise and newer.

thanks,
Ryan

[Aleksey Sanin (aleksey-l)]

Still happen on Trusty

# cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04, Trusty Tahr"

# dpkg -s slapd
Source: openldap
Version: 2.4.31-1+nmu2ubuntu8

# grep connection_read /var/log/syslog
Jun 2 10:19:02 shell slapd[1590]: connection_read(29): no connection!
Jun 2 13:07:06 shell slapd[1590]: connection_read(29): no connection!
Jun 2 13:07:06 shell slapd[1590]: connection_read(29): no connection!
Jun 2 13:10:11 shell slapd[1590]: connection_read(48): no connection!
Jun 2 16:54:05 shell slapd[1590]: connection_read(24): no connection!
Jun 2 17:12:05 shell slapd[1590]: connection_read(31): no connection!
Jun 2 19:03:37 shell slapd[1590]: connection_read(27): no connection!

[Ryan Tandy (rtandy)]

Hi Aleksey,

It's normal for slapd to emit that message if a client disconnects without unbinding. If you turn slapd's loglevel up a bit, say to "stats", you should see enough information preceding that message to tell whether that's the case.

If you see that message even though every client did an unbind before disconnecting, can you tell us some more about the conditions where you see it, or a way to reproduce?

[Aleksey Sanin (aleksey-l)]

Hi Ryan,

Yep, I read the upstream bug and understand the explanation. I was just surprised to see the bug "fixed" and I assumed it meant the error should go away completely.

In my case the error happens from Postfix -> Cyrus SASL -> PAM -> LDAP (all stock packages including stock LDAP client library).