Re: Suggest slapd loglevel

[Matthew J Backes <lucca@csun.edu>]

On Thu, 12 Sep 2002 16:30:07 -0500 (CDT)
Caylan Van Larson <caylan@cs.und.edu> wrote:

> I have a crucial ldap server that is sick.  It (slapd) dies about 5 times 
> a day.  

Ouch.

> This is reoccuring on all 3 of our ldap servers (2 slaves), so I am
> thinking it is a configuration issue on our main public server
> (mail,www,ftp,ssh) or just a config error on the ldap servers.

> I have the log level set at 256 and I am getting decent logs.  I have 
> narrowed down the crash patterns.  It seems that LDAP does not like 3 or 4 
> users.  One in particular is a username, for this purpose lets say 
> danielk, is the last searched username before 90% of the crashes.

If it were just one server, it would sound like corrupt index
databases for uid perhaps.  But multiple servers makes that somewhat
less likely.

Just to check: have you tried dumping and reloading the master from
ldif?  Are you building the replicas from ldif or trying to copy the
same databases from the master?

Does it crash on searches not involving uid?  Or involving uid and not
objectclass?

If you set up a clean independent slapd elsewhere with only that
object, do you get the same problem?  If so, that's a very interesting
object.

> What log level can I run this at so I can get the reason why it
> crashes!!!

Additional logging will hurt your performance, so be prepared for it.
The manpage for slapd.conf (5) has the loglevels...

                      1      trace function calls
                      2      debug packet handling
                      4      heavy trace debugging
                      8      connection management
                      16     print out packets sent and received
                      32     search filter processing
                      64     configuration file processing
                      128    access control list processing
                      256    stats log connections/operations/results
                      512    stats log entries sent
                      1024   print communication with shell backends
                      2048   entry parsing

Maybe try adding 1 to your loglevel to see if we can get a picture of
where it goes.  2048 may also be of interest, depending on the
problem.

Matthew Backes
lucca@csun.edu