[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Suggest slapd loglevel

On Thu, 12 Sep 2002, Matthew J Backes wrote:

> 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 thought this orginally because or IMAP daemon kept issuing requests for 
uid=imapshared (and imappublic).  This was associated whenever mail was 
being checked from a client.  I added the users imapshared/imappublic into 
the local passwd file on the mail server and immediately there were no 
more requests hitting the ldap server(s).  This did not fix the 
intermitent crashes.

> > 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?

No, I am afraid to.  Is this just as easy as running slapcat dumping to 
file and turning off ldap, deleting the db files and then running slapadd?

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

I am not successfull in reproducing the crahes :(

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

I dont have the time to do this one.  I dont think it would help me solve 
my problem.

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

I know of the numbers but I was wondering if someone had any experience 
with getting "good" crash related information out of the logs.

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

Time will tell :)

> Matthew Backes
> lucca@csun.edu