Re: Requests block when ldap server is not available
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
Re: Requests block when ldap server is not available
- From: Arthur de Jong <arthur [at] arthurdejong.org>
- To: nss-pam-ldapd-users [at] lists.arthurdejong.org
- Subject: Re: Requests block when ldap server is not available
- Date: Sun, 10 May 2020 14:56:53 +0200
On Wed, 2020-05-06 at 06:59 +0200, duncan-lists@uniqfeed.com wrote:
> May I include the strace of what is happening for the command id
> <localuser>
>
> 07:20:37 connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nslcd/socket"},
> 23) = 0
> 07:20:37 poll([{fd=3, events=POLLOUT}], 1, 10000) = 1 ([{fd=3,
> revents=POLLOUT}])
> 07:20:37 sendto(3, "\0\0\0\2\0\4\0\2\0\0\1\366", 12, MSG_NOSIGNAL, NULL, 0) =
> 12
> 07:20:37 poll([{fd=3, events=POLLIN}], 1, 60000) = 1 ([{fd=3,
> revents=POLLIN|POLLHUP}])
> 07:20:57 read(3, "\0\0\0\2\0\4\0\2", 1024) = 8
> 07:20:57 poll([{fd=3, events=POLLIN}], 1, 60000) = 1 ([{fd=3,
> revents=POLLIN|POLLHUP}])
>
> What is happening in the 20 seconds of the poll? It looks like the
> process is trying to access the LDAP server timeout which is taking
> 20.
Above is the communication between the NSS module and nslcd. The nslcd
process performs the LDAP query and the NSS module is just waiting for
a reply. After 20 seconds it gets the first part of the reply. This
part of the reply should be sent right after nslcd has read the request
(before the LDAP query is executed) so it could be that too many nslcd
threads are busy (5 by default).
Having the nslcd debug log could provide more insight into why this is
taking so long.
Kind regards,
--
-- arthur - arthur@arthurdejong.org - https://arthurdejong.org/ --