Bug 667204
| Summary: | Random search results | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Diego Woitasen <diego> | ||||
| Component: | Directory Server | Assignee: | Rich Megginson <rmeggins> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Chandrasekar Kannan <ckannan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 1.2.6 | CC: | andrey.ivanov, benl, dirks.0815 | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-03-16 22:30:42 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
I'm not sure what 389 DS 1.2.6 on Debian is exactly - is it based on the source of 389-ds-base-1.2.6, 1.2.6.1, etc.? I'm not sure what you mean by different results. Do you mean that the initial search of objects = ldap_conn.search_s(ldap_base, ldap.SCOPE_SUBTREE, 'objectClass=posixAccount') does not return all objects which have objectClass=posixAccount ? If not, how many objects does it return? Do the individual uid=value filter searches work? Can you paste excerpts from your 389 ds access log showing the objectClass=posixAccount search request and result? Yes, based on the source 389-ds-base-1.2.6.tar.bz2. Sorry, I didn't explain that point. The initial search works fine (returns all the expected objects). The second search, the individual, fails. But it fails random, with different objects in different executions. access log (first execution): [04/Jan/2011:18:46:22 -0300] conn=216004 op=1 SRCH base="dc=mrec,dc=ar" scope=2 filter="(uid=tng)" attrs=ALL [04/Jan/2011:18:46:22 -0300] conn=216004 op=1 RESULT err=0 tag=101 nentries=0 etime=0 access log (second execution): [04/Jan/2011:18:48:30 -0300] conn=227198 op=1 SRCH base="dc=mrec,dc=ar" scope=2 filter="(uid=tng)" attrs=ALL [04/Jan/2011:18:48:30 -0300] conn=227198 op=1 RESULT err=0 tag=101 nentries=1 etime=0 The individual search should always return something because the individual search is based on the full search over the directory. Looks very similar to the bug 643532 (In reply to comment #3) > Looks very similar to the bug 643532 Yes, could be. Well spotted. Can you try to reproduce this problem with 1.2.7.5 which is the latest stable version? Ok, give me a few days. Well, i've installed 1.2.7.5 on CentOS 5.5 and I couldn't reproduce the bug. Then I upgraded to 389-ds-base-1.2.7.5.tar.bz2 on my Debian server and I have the same problem again. Any idea? A problem caused for a dependency? (In reply to comment #6) > Well, > i've installed 1.2.7.5 on CentOS 5.5 and I couldn't reproduce the bug. Then I > upgraded to 389-ds-base-1.2.7.5.tar.bz2 on my Debian server and I have the same > problem again. > > Any idea? A problem caused for a dependency? What are the dependencies on Debian? What version of mozldap are you using on Debian? How is it built? I use the scripts published in the list: http://lists.fedoraproject.org/pipermail/389-users/2010-October/012253.html mozldap: 6.0.5, Compiled with: # configure ./configure --prefix=/ \ --libdir=/usr/lib/ \ --includedir=/usr/include/mozldap \ --oldincludedir=/usr/include/mozldap \ --sysconfdir=/usr/share/mozldap/etc/ \ --bindir=/usr/lib/mozldap/ \ --enable-clu \ --with-nss-inc=/usr/include/nss/ \ --with-nss-lib=/usr/lib/ \ --with-nspr-inc=/usr/include/nspr/ \ --with-nspr-lib=/usr/lib/ \ --with-svrcore-inc=/usr/include \ --with-svrcore-lib=/usr/lib \ --with-sasl 389-ds compiled with: CPPFLAGS=-DNETSNMP_USE_INLINE=1 ./configure \ --prefix=/opt/dirsrv \ --enable-bundle \ --localstatedir=/var \ --sysconfdir=/etc \ --datadir=/usr/share \ --mandir=/usr/share/man \ --with-svrcore-inc=/usr/include \ --with-svrcore-lib=/usr/lib \ --with-ldapsdk-inc=/usr/include/mozldap/ \ --with-ldapsdk-lib=/usr/lib/ \ --with-ldapsdk-bin=/usr/lib/mozldap \ --with-nss-inc=/usr/include/nss/ \ --with-nss-lib=/usr/lib/ \ --with-nspr-inc=/usr/include/nspr/ \ --with-nspr-lib=/usr/lib/ \ --with-icu-inc=/usr/include/unicode \ --with-icu-lib=/usr/lib \ --with-icu-bin=/usr/bin \ --with-sasl \ --with-kerberos Dependencies of 389-ds-base: For building: perl libnspr4-0d libnss3-dev libnspr4-0d libnss3-1d libdb4.6 libdb4.6-dev libicu38 libicu-dev libsnmp-base libsnmp15 libsnmp-dev lm-sensors libapr1-dev libpam0g-dev libaprutil1-dev libldap2-dev libsasl2-dev pkg-config libperl-dev krb5-config For running: mozldap, mozldap-tools, libnspr4-0d, libnss3-1d, libnss3-tools, perl, libsvrcore, libicu38, libdb4.6, libsnmp-base, libsnmp15, libsasl2-2 Dependencies of mozldap: for building: perl build-essential pkg-config libnspr4-0d libnss3-dev libnspr4-dev libnss3-1d libsasl2-dev bzip2 libsasl2-2 for running: libc6, libsasl2-2, libnspr4-0d, libnss3-1d, libsvrcore I can report the same problem: nearly 80000 entries in the directory. first script (python) searches all mail entries in the directory > ~28000 hits on every run - this is correct (nothing in error logs) second script searches all mailmessagestore in the directory > ~ 27000 hits on every run - this is correct (nothing in error logs) but if I start both scripts simultanously the results are different every time (~25000 hits), searches return no errors. The error log of the dirsrv have a lot of entries like these: [25/Feb/2011:08:42:08 +0100] id2entry - str2entry returned NULL for id 39674, string="rdn" [25/Feb/2011:08:42:09 +0100] id2entry - str2entry returned NULL for id 42923, string="rdn" [25/Feb/2011:08:42:09 +0100] id2entry - str2entry returned NULL for id 13678, string="rdn" [25/Feb/2011:08:42:10 +0100] id2entry - str2entry returned NULL for id 13977, string="rdn" [25/Feb/2011:08:42:10 +0100] id2entry - str2entry returned NULL for id 44248, string="rdn" [25/Feb/2011:08:42:10 +0100] id2entry - str2entry returned NULL for id 15073, string="rdn" [25/Feb/2011:08:42:11 +0100] id2entry - str2entry returned NULL for id 15685, string="rdn" dbscan -f id2entry.db4 shows all ids Version: 389-ds-base-1.2.6.1 (in 1.2.5 everything works fine) I will test 1.2.7.5 the next days... Would it be possible for you try to reproduce with 1.2.8.a3? (In reply to comment #9) > I can report the same problem: DirkS, platform? This bug is closed for me. The problem was fixed upgrading to 1.2.8rc1. |
Created attachment 471735 [details] Script to reproduce the problem. Description of problem: Testing a Python script, I found that sometimes 389 DS return different results to the same search filter. I wrote another script to verify the problem which gets every object from the DS and then search each one in the same server. If you run the script several times, the results are different. The object that wasn't found in the previous execution appears in the last one. I tested this against OpenLDAP with the same database and works with any problem. I have 10.000 objects in the database. Version-Release number of selected component (if applicable): 389 DS 1.2.6 (Debian Squeeze) How reproducible: Run the attached script. Let me know if you need anything else.