Re: nslcd: error reading from client: Success

[varun mittal <vmittal05 [at] gmail.com>]

>> 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 :

http://lists.arthurdejong.org/nss-pam-ldapd-users/2013/msg00002.html

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/