Re: Delay in LDAP lookups.

[jamie <jamie@staff.newberg.k12.or.us>]

I had this same problem and it was reverse dns not working that caused the
problem - jamie

On 7/15/03 8:01 AM, "Paul Wilson" <elviscious@rmci.net> wrote:

> I would probably suspect a dns lookup issue myself.
> 
> Probably the first place I would start is putting the server into debug
> mode (-d# when you start slapd, 1 is always a good debug level to start
> at).   Watch the output to see if anything obvious pops up, or doesn't.
> For instance, as soon as you try that command you should see searches...
> etc scrolling by.  If you aren't then it's probably a dns resolution
> problem.
> 
> pwilson
> 
>> I'm running LDAP as my authentication mechanism on all my Linux
>> boxen. On all but one -- my primary fileserver, of course -- it works
>> super-duper fine.  On the primary fileserver, however, there's roughly a
>> five-second delay for _EVERY_ DLAP lookup.  For example:
>> 
>> kend@nebula:~$ time cd ~kend
>> 
>> real    0m5.015s
>> user    0m0.010s
>> sys     0m0.000s
>> 
>> And ~kend is local!  Furthermore, it doesn't matter if I'm querying a
>> remote host, or a local replica.  Lastly, nscd won't even start:
>> 
>> root@nebula:/etc# nscd -d
>> 30376: handle_request: request received (Version = 2)
>> 30376:  GETPWBYUID (0)
>> 30376: Haven't found "0" in password cache!
>> Segmentation fault
>> 
>> If anyone has any ideas, I would be *INCREDIBLY* appreciative, because
>> this is becoming a huge issue.  Oh: this is a Debian client, and I've
>> already uninstalled/re-installed all relevant LDAP client stuff, and
>> then copied over my config files from another functioning Debian client.
>>  I'm sooooo stumped.
>> 
>> -Ken
> 
> 
> 
>