lists.arthurdejong.org
RSS feed

Re: nslcd: error reading from client: Success

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

Re: nslcd: error reading from client: Success



>> The error is easy to reproduce on our setup. The number of lookups
>> should not be lot as it's a controlled test system. But I can confirm
>> this with network trace.
>> I did run nslcd with '-d' but I'll need more d's to get useful info :)
Yes, the number of lookups are too few

>> Yes, the number of FD is about 1200-1400 in our case
>> What should we be looking for in debug mode to confirm this
>> is our issue ?
The issue turned out to be the FDs only. Reduced FDs, and issue gone
Running 'nscd' also fixed that. However, I tested nss-pam-ldapd package
of our version by cherry picking those 2 fixes and that seemed to work too

>> Increasing the thread in nss-pam-ldapd seemed to improve results
Increasing the number of threads didn't in our case.

Thanks for all the help, much appreciated :)


On Sun, Jun 1, 2014 at 10:48 AM, varun mittal <vmittal05 [at] gmail.com> wrote:
Sorry for the repost and thanks for your quick response
> You are seeing
>   nslcd: error reading from client: Success
> in the logs when the chown is issued? Is this on the NFS server or the
> client?

Yes, when the client issues chown, the client side operations succeeds but the NFS server logs this. But the ownership set on the file is wrong

> The easiest way to get more information is to run nslcd in debug mode to
> see what is going on. Is the error easy to reproduce? Are there a lot of
> lookups going on?
The error is easy to reproduce on our setup. The number of lookups should not be lot as it's a controlled test system. But I can confirm this with network trace. I did run nslcd with '-d' but I'll need more d's to get useful info :)

> The thread pointed out above was about nslcd not handling queries well
> when it is overloaded.

nslcd should not be overloaded in our case during this test as I mentioned above


> If there are applications with more than FD_SETSIZE (commonly 1024) file
> open NSS lookups will fail (conceivably with the error message you're
> seeing). The 0.8 version should handle such situations much better.

Yes, the number of FD is about 1200-1400 in our case. What should we be looking for in debug mode to confirm this is our issue ?
Does this mean that this issue could be due to 2 reasons:
1. overloaded nslcd, OR          ## Not our scenario
2. >FD_SETSIZE fd's              ## Our scenario

> Another option is to increase the number of threads. This will reduce
> the number of applications that are waiting on NSS lookups but may
> increase the load on your LDAP server.

Increasing the thread in nss-pam-ldapd seemed to improve results. I'll confirm this again.


On Fri, May 30, 2014 at 5:17 PM, varun mittal <vmittal05 [at] gmail.com> wrote:
Hi
Our setup is RHEL 6.4 with nss-pam-ldapd version nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64

We are seeing this nslcd error when clients are trying 'chown' over NFS shares.
After searching over the net I cam across this :

Though the error message is not same, but looks like the issue is the same. Not sure though !!
After increasing the number of threads from default 5 to 16, the error seems to go away

So my queries are:
1. How to confirm that our issue is the same one ?
2. The link seems to suggest it's an application side issue and not an nss-pam-ldapd issue. Is that correct ? Can we get more details about the issue and the fix ?

Thanks and regards
Mittal


-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/