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