RSS feed

Re: [PATCH] increase hardcoded timeouts

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: [PATCH] increase hardcoded timeouts

On Sun, 2016-09-25 at 01:47 -0700, Patrick McLean wrote:
> Yes, I know that it is in the socket. We were experiencing issues
> when the LDAP server was across the ocean where the increased delay
> in the server getting a response was causing the client to misbehave.
> We would see users occasionally not be able to log in, and
> disappearing from certain groups (which can be a bit of an issue when
> you rely on group membership for sudo access control).

Thanks, that clarifies things.

It is probably better to run an LDAP proxy closer. That will increase
performance and reduce latency. Running slapd with the pcache overlay
should be pretty straightforward.

If your LDAP queries take more than 60 seconds to respond you will slow
things down a lot. Most applications assume that calls to getpwnam()
and friends are relatively quick.

  the time the NSS (and PAM) module will wait for an answer from nslcd
  the time the NSS (and PAM) module will wait until it can send the
  the time the NSS module will try to read results from nslcd when
  aborting the request
  the time nslcd will wait for the written request from the module
  the time nslcd will wait until all provided results are consumed by
  the module

If nslcd is not overloaded having default values common/nslcd-
prot.c:WRITE_TIMEOUT and nslcd/nslcd.c:READ_TIMEOUT should be OK. The
only case when these values could be increased is when it takes too
long for nslcd to read the request (not the processing time, just the
time it takes to accept the initial connection).

If your LDAP server takes more than 60 seconds to respond you could
increase nslcd/nslcd.c:WRITE_TIMEOUT and common/nslcd-

Also, if your LDAP server is so slow that all nslcd threads are
regularly busy, you could increase the number of threads so more
requests can run in parallel.

-- arthur - - --
To unsubscribe send an email to or see