The primary tool for troubleshooting OpenLDAP problems is the slapd log file. The location of this file is set in the configuration files (slapd.conf or slapd.ldif). The default is /opt/symas/openldap/slapd.log. For more details please see @How to use debug logging.

Symas has written a number of utility programs that produce simple summary information about a slapd log file. It can be downloaded from our git repository. For more information see Symas Log Reduction Tools.

For production server Symas recommends stats and sync log level (logLevel / olcLogLevel in the configuration)

Logs are usually rotated on a regular basis and only stored for a period of time. They are useful when there are issues that need to be investigated, such as issues with performance, unexpected error codes in client applications or servers unexpectedly shutting down.

General Format of a Log Record

The log records have two basic parts. 

• The first part contains date-time-stamp, name of the host/server, and process name with the process ID in brackets. This part is terminated by a colon.

2025-07-07T07:19:10.541652+00:00 ldap_server slapd[4153]:

• The second part of the log record is the actual logged data. This part of the line starts with the connection number (conn=1234), and either a file descriptor number (fd=123 , only on ACCEPT requests) or an operation number (op=0). The rest of the data depends on the type of the log entry.

conn=1003 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=jdoe)" 

There are 3 types of log entries:

1. LDAP request related entries (STATS logging level). These entries log request and result information for every LDAP operation serviced by the OpenLDAP server. 
2. syncrepl processing related entries (SYNC logging level). These entries record the Consumer's activities processing updates from servers providing them replication feeds (Producers/Masters…). 
3. other entries - include records about slapd startup and shutdown and unindexed attributes referenced in search filters.

Connections and File Descriptors

When OpenLDAP receives an ACCEPT request (a request for a new connection) it creates a file descriptor for this connection (fd=). ACCEPT also performs the TLS verification for encryption and security if TLS is set up. If there are issues with establishing the TLS connection the connection is closed with “TLS negotiation failure” error.

LDAP Request Related Log Entries

Once a connection is established, LDAP requests will each be given a sequence number within the connection (op=0, op=1…). Since there can be often be mutliple requests at a time, the various log records will be intermixed and the order needs to be figured out “manually" by following the conn= op= through the log.

The first request after ACCEPT is generally a BIND, establishing the identity of the principle requesting the service, authenticating them for use and checking permissions for subsequent requests. 

BIND pattern

conn=1234 op=0 BIND dn="cn=bowser,ou=puppies,dc=example,dc=com" <bind method>
conn=1234 op=0 RESULT tag=97 err=0 qtime=0.000017 etime=0.000456 text=

Often there are several BIND records as OpenLDAP and the client LDAP application negotiate to establish a connection at a security level demanded by the OpenLDAP configuration's settings.

SRCH pattern

conn=1003 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=jdoe)"
conn=1003 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

ADD pattern

conn=1004 op=2 ADD dn="uid=newuser,ou=People,dc=example,dc=com"
conn=1004 op=2 RESULT tag=105 err=0 text=

MODIFY pattern

conn=1006 op=4 MOD dn="uid=jdoe,ou=People,dc=example,dc=com"
conn=1006 op=4 MOD attr=mail
conn=1006 op=4 RESULT tag=103 err=0 text=

Other openLDAP operations include COMPARE (checking if a specified attribute in an entry has any value), DELETE (removeing entry or DN), RDN (modify DN) and ABANDON (cancel a previously started operation).

Important key words

• tag  

Tags are internal flags within OpenLDAP. 

• err

The err information is an LDAP Return Code as defined in the RFC. You can find an annotated list in LDAP Result Codes . Note that err=0 refers to suffess and therefore not an error

• qtime

qtime is the time, in microseconds, the request was in a queue waiting to be dispatched for processing. qtime is normally very small and consistent. When it is higher, it indicates that OpenLDAP is constrained somehow and may indicate the nedd for more resources.

• etime

etime is the time, in microseconds, OpenLDAP took to process the request. Etimes are highly variable because each request presents OpenLDAP with varying levels of complexity and demands on database handling.

• nentries

nentries reports the number of entries returned. 

syncrepl Related Log Entries

initiall sync request

do_syncrep1: rid=008 starting refresh (sending cookie=rid=008,csn=20250701015622.605818Z#000000#001#000000;20250610103915.562313Z#        000000#002#000000)                                                                                                                                                                 do_syncrep2: rid=008 LDAP_RES_SEARCH_RESULT                                                                         

do_syncrep2: rid=001 finished refresh phase
do_syncrep2: rid=001 cookie=csn=20250710121000Z#000000#00#000000 

Sync Error Example

do_syncrep2: rid=001 retrying (sleeping 30 seconds)... do_syncrep2: rid=001 ldap_search_ext failed (81) 

Entry Update Log

syncrepl_entry: rid=001 be_search (uid=jdoe) syncrepl_entry: rid=001 entry updated uid=jdoe,ou=People,dc=example,dc=com 

syncrepl_entry: rid=001 entry deleted uid=olduser,ou=People,dc=example,dc=com

• rid

Identifies a consumer locally within the consumer server.

• csn 

part of the cookie that indicates the latest state of the entry or database of the consumer. It is usefult for tracking down the records between the provider and the consumer logs.

Other Interesting Entries

Startup records example

Jul 10 14:32:10 ldap-server slapd[12345]: @(#) $OpenLDAP: slapd 2.5.13 (May 15 2024) $
Jul 10 14:32:10 ldap-server slapd[12345]: daemon: IPv6 socket created
Jul 10 14:32:10 ldap-server slapd[12345]: daemon: IPv4 socket created
Jul 10 14:32:10 ldap-server slapd[12345]: slapd init: initiated server.
Jul 10 14:32:10 ldap-server slapd[12345]: slap_sasl_init: initialized!
Jul 10 14:32:10 ldap-server slapd[12345]: bdb_db_open: dc=example,dc=com
Jul 10 14:32:10 ldap-server slapd[12345]: bdb(dc=example,dc=com): Logging region out of memory; you may need to increase shared region size
Jul 10 14:32:10 ldap-server slapd[12345]: bdb_db_open: database "dc=example,dc=com": dbenv_open(/var/lib/ldap)
Jul 10 14:32:10 ldap-server slapd[12345]: slapd starting
Jul 10 14:32:10 ldap-server slapd[12345]: syncrepl: rid=001 starting sync with ldap://ldap-master.example.com
Jul 10 14:32:11 ldap-server slapd[12345]: slapd started. Listening on 0.0.0.0:389 and [::]:389

Shutdown records example

Jul 10 18:02:50 ldap-server slapd[12345]: slapd shutdown: initiated
Jul 10 18:02:50 ldap-server slapd[12345]: slapd shutdown: waiting for 5 operations/tasks to finish
Jul 10 18:02:50 ldap-server slapd[12345]: syncrepl: rid=001 stopping sync
Jul 10 18:02:50 ldap-server slapd[12345]: slapd shutdown: closing listeners...
Jul 10 18:02:50 ldap-server slapd[12345]: slapd shutdown: releasing resources
Jul 10 18:02:50 ldap-server slapd[12345]: slapd shutdown: BDB closed
Jul 10 18:02:50 ldap-server slapd[12345]: slapd stopped.