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

Bug #594840 reported by Mark A. Ziesemer on 2010-06-15
This bug affects 20 people
Affects Status Importance Assigned to Milestone
openldap (Debian)
Fix Released
openldap (Ubuntu)

Bug Description

Reported upstream at , 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 , 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

Mark A. Ziesemer (ziesemer) wrote :
Thierry Carrez (ttx) on 2010-06-16
Changed in openldap (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Kjell Braden (afflux) wrote :

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:

:msg, contains, ": no connection" ~

Marcio Merlone (mmerlone) wrote :

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).

description: updated
airtonix (airtonix-gmail) wrote :

still occuring

Mark A. Ziesemer (ziesemer) wrote :

Some interesting comments left in the notes field at :

fixed in master
fixed in RE24

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

description: updated
Ryan Tandy (rtandy) wrote :


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


Changed in openldap (Debian):
importance: Undecided → Unknown
status: New → Unknown
Changed in openldap (Ubuntu):
status: Confirmed → Fix Released
Changed in openldap (Debian):
status: Unknown → Fix Released
Aleksey Sanin (aleksey-l) wrote :

Still happen on Trusty

# cat /etc/os-release
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) wrote :

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) wrote :

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).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.