Bug 495701 - LDAP queries fail entirely on a (temporarily) slow server
LDAP queries fail entirely on a (temporarily) slow server
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap (Show other bugs)
x86_64 Linux
medium Severity high
: beta
: ---
Assigned To: Jan Zeleny
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-04-14 09:14 EDT by Albert Flügel
Modified: 2014-08-14 10:37 EDT (History)
4 users (show)

See Also:
Fixed In Version: nss_ldap-253-22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-30 04:05:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch fixing this issue (654 bytes, patch)
2009-10-19 10:02 EDT, Jan Zeleny
no flags Details | Diff

  None (edit)
Description Albert Flügel 2009-04-14 09:14:38 EDT
Description of problem:
When the LDAP server of this client is slow, after about 10 seconds a query for an account (ou=People) or a host (ou=Hosts) makes the respective program (e.g. getent) print out the error message:
getent: ../../../libraries/libldap/error.c:273: ldap_parse_result: Assertion `r != ((void *)0)' failed.

Version-Release number of selected component (if applicable):

How reproducible:
make the LDAP server of this client slow in some way, e.g. renice to a low priority and make the server busy so the ldap service is really slow.

Steps to Reproduce:
1. getent passwd <whatever-valid-account-name-in-ldap>
Actual results:
getent: ../../../libraries/libldap/error.c:273: ldap_parse_result: Assertion `r != ((void *)0)' failed.

Expected results:
normal getent output

Additional info:
Seems not to happen on RedHat-EL4 or 3.
Seems, fallback to another LDAP server does not work in this situation.
When the slow LDAP server is back to normal speed, the client with this openldap version stays in this status. nscd must be restarted, otherwise the problem persists.
Comment 2 Jan Zeleny 2009-04-28 07:53:07 EDT
I didn't manage to reproduce this bug, I tried several hundred times:

1. Renice slapd to +19
2. Stress the machine (stress --cpu 20 --vm 20 or stress --cpu 10 --vm 10 --io 10 --hdd 10).
3. for i in `seq 1 100`; do getent passwd <user>; echo $i; done

I tried this both on 32 bit system and 64 bit system. I also tried to set smaller values of timeouts in /etc/ldap.conf. In extreme cases getent hang until system was no longer stressed, but not a single crash.

Do you have any more info about this issue? If not, I'm sorry, but I'm going to close this bug as WORKSFORME.
Comment 3 Albert Flügel 2009-05-06 04:47:43 EDT
Sorry for this issue. Seems we are quite often having problems noone else has
in the world :-( . Probably due to a relatively large scale and heavily loaded
environment. Sorry i have no more info about this problem. Probably with
a newer openldap release this is gone anyway (?).
Comment 4 Jan Zeleny 2009-05-06 05:03:15 EDT
Ok, for now I'm closing this bug. Please re-open this issue if problems persist in newer versions of openldap.
Comment 5 timlank 2009-06-24 15:04:33 EDT
We're experiencing this also - Red Hat SR#1930570

while in an NFS mounted directory, I ran "ls -l" and got the following:
ls: ../../../libraries/libldap/error.c:273: ldap_parse_result: Assertion `r != ((void *)0)' failed

Subsequent invocations of "ls -l" ran fine.

Our master OpenLDAP doesn't seem to be taxed much though.

# rpm -qa | grep ldap
[root@ai13-07 /]# uname -a
Linux ourserver 2.6.18-128.1.10.el5 #1 SMP Wed Apr 29 13:53:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Comment 6 timlank 2009-07-03 08:31:41 EDT
This seems to be resolved by increasing the nss_ldap bind_timeout parameter.  I had it at 2 from a RHEL4 environment.  Increasing this to 120, while it may be overkill, resolved the problem.  We'll likely end up reducing this to a comfortable level that does not invoke the error.
Comment 7 Albert Flügel 2009-07-03 08:42:54 EDT
Anyway this is a workaround and does not solve the actual problem. The client should try to bind to the next configured server. Having tried all servers, it should issue a warning, probably fail later. When behaving this way, there might be an additional parameter to configure e.g. allservers_fail_timeout.
Comment 8 Jan Zeleny 2009-07-03 08:47:20 EDT
Since this error seems to live, I'm reopening this bug and will be investigating it.
Comment 10 Jan Zeleny 2009-10-19 10:02:01 EDT
Created attachment 365239 [details]
Patch fixing this issue

I backported patch from upstream, it should eliminate the issue.
Comment 13 Jan Zeleny 2009-11-16 04:48:55 EST
Patch is in CVS, changing status to MODIFIED.
Comment 15 Ondrej Moriš 2010-01-29 07:29:28 EST
Bug reported in description is not caused by openldap.

It's the nss_ldap bug (see BZ499302). However, this bug was fixed in 5.4.z, so it is not expected to be reproducible unless you downgrade to nss_ldap < 253-22. NFS bug reported in Comment #5 is very probably the same nss_ldap problem. 

Please note that this problem was fixed in nss_ldap itself which is built with static copy of libldap.

It's reasonable to apply proposed patch to openldap, but of course it can't affect nss_ldap now.

Hence I suggest to close this bug with NOTABUG, CURRENTRELEASE or DUPLICATED (BZ499302).
Comment 16 Ondrej Moriš 2010-01-29 17:19:26 EST
Please see Comment 15 first. 

You should have installed nss_ldap-253-22 to avoid described bugs (getent, nfs). 

Since this bug is not directly caused by openldap, we perform sanity checks only - patched openldap must work correctly without any regression.

Sanity verification successfull on RHEL5.5-{Client,Server}-20100129.nightly.
Comment 18 errata-xmlrpc 2010-03-30 04:05:24 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.