Re: [nssldap] Looking for support on nss_ldap issue

["Douglas E. Engert" <deengert [at] anl.gov>]

nssldap@evilbrain.com wrote:
> On Tue, 17 Nov 2009, Douglas E. Engert wrote:
> > I don't have a CentOS system but we ran into issues with lost connections
> > and TLS. This sounds a lot like:
> >
> > BUG #392: call do_close() if ldap_result() or ldap_parse_result()
> >          fails (before returning NSS_UNAVAIL)
> >
> > and not having a timelimit set.
> >
> > Fixes for these are in nss_ldap-265 announced on 11/6/2009
> >
> > You may want to try using this newer version, if only to see if it fixes
> > your problem even if CentOS does not have this version yet.
> >
> > Since this looks like issues with timeouts
> > You may also want to set:
> >
> > idle_timelimit 20
> > timelimit 30
> >
> > Good luck.
>
> Thanks!  I have attached a document.
>
> I downloaded the source for that version that you describe and built it 
> into packages for my CentOS machines.  I tried it out, but I still 
> encounter the timeout related failure.  I added the following lines to 
> ldap.conf but to no avail:
>
> bind_timelimit          5
> idle_timelimit 5
> timelimit 5
>
> My LDAP servers are local and are not stressed, so I figured a low 
> timeout would be acceptable.
>
> The server that I hit with SIGSTOP that is detailed in the debug output 
> was ldap1.management.example.com .
>
> Any additional help would be appreciated, thanks again!

I am no ldap expert, hopefully someone from Padl will respond.

But if you have all the timeouts set on the client, why
does this line near the end say infinite timeout?

wait4msg ld 0x55556e6dde40 msgid 1 (infinite timeout)

> > --
> >
> > Douglas E. Engert  <DEEngert@anl.gov>
> > Argonne National Laboratory
> > 9700 South Cass Avenue
> > Argonne, Illinois  60439
> > (630) 252-5444

--

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444