OpenLDAP Faq-O-Matic : OpenLDAP Software FAQ : When all else fails... :
Check the log for errors?|
|Turn on logging in the configuration file and check the log for configuration errors. The directive in slapd.conf is:|
Or, you can add 64 to the loglevel you use.
Then, add line to /etc/syslogd.conf like:
(This writes _every_ log record to /var/log/debug!)
Don't forget to restart slapd and syslogd. And don't forget to undo the
change to /etc/syslogd.conf when you're done or you could fill your disk
with log records!
See also the -l option of slapd and the loglevel directive of slapd.conf.
The OpenLDAP suite comes with a tool, called slaptest(5), that checks for errors in the configuration file. Run it as much as you would with slapd itself and see if it succeeds:
[user@host tests]$ slaptest -f testrun/slapd.1.conf
config file testing succeeded
See the man page for useful options. In detail, slaptest tries all the initializations that slapd would do, except for initializing the listeners. If the databases cannot be successfully started up, it fails suggesting what could be wrong, desite the configuration file being correct. For instance, a common error is to start slapd before creating the database directory. The result of running slaptest with an otherwise correct configuration file is:
[user@host tests]$ slaptest -f testrun/slapd.1.conf -d 256
bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003)
hdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003)
bdb_db_init: Initializing BDB database
bdb_db_open: db_open(./testrun/db.1.a/id2entry.bdb) failed: No such file or directory (2)
backend_startup: bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)
When slapd is running, you may change the log level without stopping it if you are using the monitor backend. Slapd must be configured with
and there must be at least one identity that can write to it; for example, the monitor database rootdn. Note that the rootdn does not have to be in the monitor database naming context. Otherwise, if you plan to use a generic identity, you need to make sure the ACLs grant that identity write privileges to the managedInfo attribute.
Then you need to perform a modification with an LDIF like the one reported below, for example by running ldapmodify(1):
The above adds the stats and stats2 log levels; use any of the levels listed in slapd.conf(5). Note that the values of managedInfo cannot be arbitrary; if they are not in the allowed set, the operation fails. All usual rules of LIDF modifications must be fulfilled. You may also delete specific log level values, or all of them, or replace them by a new set and so on.
|[Append to This Answer]|