- openldap-bugs - openldap.org

Re: (ITS#4715) proxy retries anonymously
by hyc＠symas.com 18 Oct '06

18 Oct '06

The proxycache has nothing to do with the connections to the remote server. That's handled by the back-ldap or whatever backend you're using. Since you haven't provided any of the relevant config info from your slapd.conf there's no way to tell what you're doing there. In fact your log shows that a Bind was performed on the retry, but it was done anonymously. So it may be something as simple as a missing config keyword (like rebind-as-user in back-ldap). Or it may possibly be related to a bug in back-ldap's retry handling as Pierangelo mentioned in his reply to you. There is no proxycache bug here. At the moment, without further details, it doesn't seem there's any OpenLDAP software bug here at all. Ashish Gawarikar wrote: > > ------------------------------------------------------------------------ > > The problem is that the connection to the backend server drops and the proxy > cache has to reestablish it. Doing this, it doesn't do a BIND again and thus > the query is executed with anonymous privileges and fails. See log file from > the backend server: -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4715) Proxy cache TTL does not seem to be working as documented
by hyc＠symas.com 18 Oct '06

18 Oct '06

Your log actually indicates that it attempted to re-query the remote server but got an error from the remote server. Sounds like you have other problems, unrelated to the proxycache. (Note that the pcache overlay never returns a NO_SUCH_OBJECT error code itself, that can only happen because the remote server returned that code.) ashish(a)ratboy.net wrote: > Full_Name: Ashish Gawarikar > Version: 2.3.27 > OS: Linux - 2.6 based > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.211.143.38) > > > Openldap 2.3.27 configured as proxy cache is behaving erratically. > > Entries being answered from the proxy cache sometimes result with a negative > result, even though the LDAP server has the information. > > It appears like the proxycache "forgets" that it has gotten the answer, but > doesn't re-query the target server to fetch the information again. > > Proxy cache returns 'no such object' for a previously found entry if the ttl > has passed between queries: > > conn=0 op=2 SRCH base="dc=mail,dc=example,dc=com" scope=2 deref=0 > filter="(mailLocalAddress=account1(a)example.com)" > conn=0 op=2 SRCH attr=maillocaladdress > request done: ld 0x83dd3b8 msgid 3 > conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=Search operation > succeeded > > <-- wait "some" time here --> > > conn=0 op=3 SRCH base="dc=mail,dc=example,dc=com" scope=2 deref=0 > filter="(mailLocalAddress=account1(a)example.com)" > conn=0 op=3 SRCH attr=maillocaladdress > conn=0 op=3 ldap_back_retry: retrying URI="ldap://ldap.example.com:389" > DN="cn=admin,dc=example,dc=com" > request done: ld 0x83dd3b8 msgid 1 > request done: ld 0x83dd3b8 msgid 2 > conn=0 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text=No such object: > dc=mail,dc=example,dc=com -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4716) syncrepl - consumer missed some delete
by Paolo.Rossi.con＠h3g.it 18 Oct '06

18 Oct '06

Full_Name: Paolo Rossi Version: 2.3.27 OS: solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.149.168.124) Hi, Doing stress test on syncrepl, 1 producer --> 1 consumer, I've found a strange issue: Afer load the openLDAP cluster (1m entry whit random 1,2 or 3 sub dn), I've used a script to make constant random changes on the producer. Meanwhile I've do some test & check on consumer. I've found a issue when, stopping the consumer for some minutes, whit a continuous load versus producer, restarting the consumer it resync itself but some DELETE operation of entire subDN went lost. Doing a search I've noticed on producer: dn: testid=106087406087,ou=profiles,dc=foo,dc=bar structuralObjectClass: profile entryUUID: e2543b6a-559a-1029-82d7-f1c24b7d324b creatorsName: cn=Manager,dc=foo,dc=bar modifiersName: cn=Manager,dc=foo,dc=bar createTimestamp: 20050510122923Z modifyTimestamp: 20050510122923Z entryCSN: 20050510122923Z#000017#00#000000 entryDN: testid=106087406087,ou=profiles,dc=foo,dc=bar subschemaSubentry: cn=Subschema hasSubordinates: FALSE but on consumer: dn: testid=106087406087,ou=profiles,dc=foo,dc=bar structuralObjectClass: profile entryUUID: e2543b6a-559a-1029-82d7-f1c24b7d324b creatorsName: cn=Manager,dc=foo,dc=bar modifiersName: cn=Manager,dc=foo,dc=bar createTimestamp: 20050510122923Z modifyTimestamp: 20050510122923Z entryCSN: 20050510122923Z#000017#00#000000 entryDN: testid=106087406087,ou=profiles,dc=foo,dc=bar subschemaSubentry: cn=Subschema hasSubordinates: TRUE dn: subtestID=106087406087,testid=106087406087,ou=profiles,dc=foo,dc=bar structuralObjectClass: profileAccount entryUUID: e25462d4-559a-1029-82d8-f1c24b7d324b creatorsName: cn=Manager,dc=foo,dc=bar modifiersName: cn=Manager,dc=foo,dc=bar createTimestamp: 20050510122923Z modifyTimestamp: 20050510122923Z entryCSN: 20050510122923Z#000018#00#000000 entryDN: subtestID=106087406087,testid=106087406087,ou=profiles,dc=foo,dc=bar subschemaSubentry: cn=Subschema hasSubordinates: FALSE ----- only on producer: hasSubordinates: FALSE I've "loglevel config acl sync" on consumer, but there is no log of sync operation on that dn. Also restarting the cluster, replica remain desynched on that dn. Solaris 8 sparc openLDAP 2.3.27 (64 bit build) BDB 4.2.52.5 hdb backend Paolo

1 0

(ITS#4715) Proxy cache TTL does not seem to be working as documented
by ashish＠ratboy.net 17 Oct '06

17 Oct '06

Full_Name: Ashish Gawarikar Version: 2.3.27 OS: Linux - 2.6 based URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) Openldap 2.3.27 configured as proxy cache is behaving erratically. Entries being answered from the proxy cache sometimes result with a negative result, even though the LDAP server has the information. It appears like the proxycache "forgets" that it has gotten the answer, but doesn't re-query the target server to fetch the information again. Proxy cache returns 'no such object' for a previously found entry if the ttl has passed between queries: conn=0 op=2 SRCH base="dc=mail,dc=example,dc=com" scope=2 deref=0 filter="(mailLocalAddress=account1(a)example.com)" conn=0 op=2 SRCH attr=maillocaladdress request done: ld 0x83dd3b8 msgid 3 conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=Search operation succeeded <-- wait "some" time here --> conn=0 op=3 SRCH base="dc=mail,dc=example,dc=com" scope=2 deref=0 filter="(mailLocalAddress=account1(a)example.com)" conn=0 op=3 SRCH attr=maillocaladdress conn=0 op=3 ldap_back_retry: retrying URI="ldap://ldap.example.com:389" DN="cn=admin,dc=example,dc=com" request done: ld 0x83dd3b8 msgid 1 request done: ld 0x83dd3b8 msgid 2 conn=0 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text=No such object: dc=mail,dc=example,dc=com

1 0

(ITS#4714) 'Connection' object not throwing LDAPException upon sudden server connection loss
by alejandro.robles＠tre.se 17 Oct '06

17 Oct '06

Full_Name: Alejandro Robles Version: n/a OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.182.141.229) SUMMARY This issue relates to JLDAP software package (novell-jldap-devel-2006.06.22-1unix.zip) whereby during a sudden server connection loss the Connection object doesn't through an LDAPException upon an LDAP Search operation. If this situation isn't detectec it causes the running thread to hang where retrieving results by first invoking hasMoreElements() method. DETAILS A client program of the form: 1{ 2 Connect; 3 Bind; 4 5 <being loop> 6 try {Search;} 7 catch (LDAPException) {<do something>} 8 while(hasMoreElements()) { 9 retrieve; 10 } 11 Sleep 10secs; 12 <end loop> 13 14 Unbind; 15 Disconnect; 16} If a connection loss is simulated while the program is sleeping (line 11), when the thread wakes up and invokes the Search method (line 6) is doesn't through an exception and thereafter the thread gets locked when running hasMoreElements() on the results (line 8). SOLUTION The cause of the problem is belived to be within the Connection object in the method 'writeMessage' (below extract from /com/novell/ldap/Connection.java object version 1.88): /* * IOException could be due to a server shutdown notification which * caused our Connection to quit. If so we send back a slightly * different error message. We could have checked this a little * earlier in the method but that would be an expensive check each * time we send out a message. Since this shutdown request is * going to be an infrequent occurence we check for it only when * we get an IOException. shutdown() will do the cleanup. */ if( clientActive) { // We beliefe the connection was alive if (unsolSvrShutDnNotification) { // got server shutdown throw new LDAPException( ExceptionMessages.SERVER_SHUTDOWN_REQ, new Object[] { host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); } // Other I/O Exceptions on host:port are reported as is throw new LDAPException(ExceptionMessages.IO_EXCEPTION, new Object[] {host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); } The fact that the Connection has been lost causes prior to issuing a search to the server to set the value of clietActive to false. The latter in turn causes that any IOExceptions within the method not be handled properly (not thrown at all) causing the mentioned problem. PROPOSED FIX To add a default Exception throwing code for the cases where 'clientActive' is false. /* * IOException could be due to a server shutdown notification which * caused our Connection to quit. If so we send back a slightly * different error message. We could have checked this a little * earlier in the method but that would be an expensive check each * time we send out a message. Since this shutdown request is * going to be an infrequent occurence we check for it only when * we get an IOException. shutdown() will do the cleanup. */ if( clientActive) { // We beliefe the connection was alive if (unsolSvrShutDnNotification) { // got server shutdown throw new LDAPException( ExceptionMessages.SERVER_SHUTDOWN_REQ, new Object[] { host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); } // Other I/O Exceptions on host:port are reported as is throw new LDAPException(ExceptionMessages.IO_EXCEPTION, new Object[] {host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); } else // Other I/O Exceptions on host:port are reported as is throw new LDAPException(ExceptionMessages.IO_EXCEPTION, new Object[] {host, new Integer(port)}, LDAPException.CONNECT_ERROR, null, ioe); }

1 0

Re: (ITS#4702) out-of-memory on huge DB ?
by paolo.rossi.con＠h3g.it 16 Oct '06

16 Oct '06

Another day, another try. Today I've tried the slapcat (32Bit) a 8 GB RAM solaris/sparc machine. also this time I had: core dumped ch_malloc of 16392 bytes failed ch_malloc.c:57: failed assertion `0' allocation at coredump was PID RSS VSZ %MEM TIME STIME COMMAND 29941 4164952 4168968 51.8 01:15:27 16:03:43 slapcat It seems the famous 4GB allocation limit on 32Bit build ? I will try the last shot, reloading a BD on a 64 Bit build; but seems the 32Bit build, had no hope to finish the task :( Paolo

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by ando＠sys-net.it 16 Oct '06

16 Oct '06

quanah(a)stanford.edu wrote: > --On Monday, October 16, 2006 5:41 AM +0000 quanah(a)stanford.edu wrote: > > > > >> I'll see if I can get a core from it. >> > > Never mind, I found the problem in slapd.1.out: > > /usr/local/build/ldap-head-20061015/servers/slapd/.libs/lt-slapd: > relocation error: ../servers/slapd/back-meta/.libs/back_meta-2-devel.so.0: > undefined symbol: ldap_back_proxy_authz_ctrl > > > Sounds like something isn't being linked right, or something isn't declared > right in the back-meta build. > Right. Back-meta occasionally reuses stuff from back-ldap; apparently I pulled et another function from there, so it seems you need to load back_ldap.la as well to use back_meta.la. I wonder if there's any better solution (e.g. statically link back_meta.la with back_ldap.la, but then there would be duplicates when one loads both?). Too bad I don't routinely check HEAD with all-modules builds, sorry. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by quanah＠stanford.edu 16 Oct '06

16 Oct '06

--On Monday, October 16, 2006 5:41 AM +0000 quanah(a)stanford.edu wrote: > I'll see if I can get a core from it. Never mind, I found the problem in slapd.1.out: /usr/local/build/ldap-head-20061015/servers/slapd/.libs/lt-slapd: relocation error: ../servers/slapd/back-meta/.libs/back_meta-2-devel.so.0: undefined symbol: ldap_back_proxy_authz_ctrl Sounds like something isn't being linked right, or something isn't declared right in the back-meta build. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by quanah＠stanford.edu 16 Oct '06

16 Oct '06

--On Monday, October 16, 2006 5:38 AM +0000 ando(a)sys-net.it wrote: > quanah(a)stanford.edu wrote: >> When running test030-relay, I get a failure. >> > works just fine here, on Linux 32 bit and Solaris 64 bit >> Basic output shows: >> >> Using meta backend... >> >> Starting slapd on TCP/IP port 9011... >> Using ldapsearch to check that slapd is running... >> Using ldapadd to populate the database... >> Searching base="dc=example,dc=com"... >> Searching base="o=Example,c=US"... >> Search failed (255)! >> ./scripts/test030-relay: line 79: kill: (20796) - No such process >> > Sounds like slapd either stopped or crashed; anything relevant from > slapd's logs (or any core dump around)? >> The ldapsearch.out file shows: >> > snip... >> # searching base="o=Example,c=US"... >> ldap_result: Can't contact LDAP server (-1) >> > This is not much indicative of the reason of the failure; see above. > Note that Saturday 14 I made sort of a mess in HEAD with daemon.c, which > I only noticed and fixed late Sunday 15; please make sure you're using > the correct files from HEAD. It is HEAD as of now, i.e., I retrieved it this evening. ;) I'll see if I can get a core from it. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by ando＠sys-net.it 16 Oct '06

16 Oct '06

quanah(a)stanford.edu wrote: > When running test030-relay, I get a failure. > works just fine here, on Linux 32 bit and Solaris 64 bit > Basic output shows: > > Using meta backend... > > Starting slapd on TCP/IP port 9011... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Searching base="dc=example,dc=com"... > Searching base="o=Example,c=US"... > Search failed (255)! > ./scripts/test030-relay: line 79: kill: (20796) - No such process > Sounds like slapd either stopped or crashed; anything relevant from slapd's logs (or any core dump around)? > The ldapsearch.out file shows: > snip... > # searching base="o=Example,c=US"... > ldap_result: Can't contact LDAP server (-1) > This is not much indicative of the reason of the failure; see above. Note that Saturday 14 I made sort of a mess in HEAD with daemon.c, which I only noticed and fixed late Sunday 15; please make sure you're using the correct files from HEAD. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4713) test030-relay broken in HEAD
by quanah＠stanford.edu 16 Oct '06

16 Oct '06

Full_Name: Quanah Gibson-Mount Version: HEAD 2006/10/15 OS: Linux 2.6 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) When running test030-relay, I get a failure. Basic output shows: Using meta backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Search failed (255)! ./scripts/test030-relay: line 79: kill: (20796) - No such process The ldapsearch.out file shows: objectClass: OpenLDAPperson cn: Ursula Hampster sn: Hampster uid: uham title: Secretary, UM Alumni Association postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com homePostalAddress: 123 Anystreet $ Anytown, MI 48104 mail: uham(a)mail.alumni.example.com homePhone: +1 313 555 8421 pager: +1 313 555 2844 facsimileTelephoneNumber: +1 313 555 9700 telephoneNumber: +1 313 555 5331 # searching base="o=Example,c=US"... ldap_result: Can't contact LDAP server (-1)

1 0

Re: (ITS#4712) test007: slapd crashes
by michael＠stroeder.com 16 Oct '06

16 Oct '06

Pierangelo Masarati wrote: > Michael Ströder wrote: > >> Yes, I learned this (again) on Friday. ;-) >> >> export CFLAGS="-g" > > Note that this does not disable optimization (AFAIK); I'd place an > explicit CFLAGS="-g -O0". Unfortunately this does not help. >> But it still does not work. >> > But in any case that doesn't seem to be the issue. What gcc are you > using? SuSE Linux 10.1 $ gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.0 (SUSE Linux) Ciao, Michael.

1 0

Re: (ITS#4712) test007: slapd crashes
by quanah＠stanford.edu 16 Oct '06

16 Oct '06

--On Sunday, October 15, 2006 10:08 PM +0000 hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Michael Str?der wrote: >>> Yes, I learned this (again) on Friday. ;-) >>> >>> export CFLAGS="-g" >>> >> Note that this does not disable optimization (AFAIK); I'd place an >> explicit CFLAGS="-g -O0". > > No, the default without any -O flag is no optimization. > >>> But it still does not work. >>> >> But in any case that doesn't seem to be the issue. What gcc are you >> using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red >> Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note >> that I don't assume this could have an impact on your issue. > > I think Michael just has a corrupt build tree. The previous issue he > reported was cleared up by running "make clean" in the back-bdb and > back-monitor directories, then rebuilding. I suspect just doing a "make > clean" from the top level and rebuilding would clear up the rest. HEAD from today builds just fine for me, with BDB 4.5, and test007 passes. OL 2.3.27 doesn't work with BDB 4.5, although I (so far) have not been able to track down a BDB 4.5 specific commit to HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4712) test007: slapd crashes
by hyc＠symas.com 16 Oct '06

16 Oct '06

ando(a)sys-net.it wrote: > Michael Ströder wrote: >> Yes, I learned this (again) on Friday. ;-) >> >> export CFLAGS="-g" >> > Note that this does not disable optimization (AFAIK); I'd place an > explicit CFLAGS="-g -O0". No, the default without any -O flag is no optimization. >> But it still does not work. >> > But in any case that doesn't seem to be the issue. What gcc are you > using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red > Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note > that I don't assume this could have an impact on your issue. I think Michael just has a corrupt build tree. The previous issue he reported was cleared up by running "make clean" in the back-bdb and back-monitor directories, then rebuilding. I suspect just doing a "make clean" from the top level and rebuilding would clear up the rest. This does point out a bug in the slapd Makefile; for dynamic backends it appears to not remake the backend directories if they have already been built once. I'll look into that... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4712) test007: slapd crashes
by ando＠sys-net.it 15 Oct '06

15 Oct '06

Michael Ströder wrote: > Yes, I learned this (again) on Friday. ;-) > > export CFLAGS="-g" > Note that this does not disable optimization (AFAIK); I'd place an explicit CFLAGS="-g -O0". > But it still does not work. > But in any case that doesn't seem to be the issue. What gcc are you using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note that I don't assume this could have an impact on your issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4712) test007: slapd crashes
by michael＠stroeder.com 15 Oct '06

15 Oct '06

Pierangelo Masarati wrote: > > this backtrace looks weird, because: > - bconfig.c:2734 is not in config_replica() in HEAD right now, and, > according to cvsweb, the last commit to bconfig.c occurred 4 weeks ago > (unless you modified that file yourself) The only modifications to my HEAD source tree are happening through cvs up -RdP . > You should really cross-check what you're debugging, or something else > is going berserk. Maybe try without optimization? Yes, I learned this (again) on Friday. ;-) export CFLAGS="-g" But it still does not work. Ciao, Michael.

1 0

Re: (ITS#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it 15 Oct '06

15 Oct '06

> > slapcat -f slapd.conf > > > So you understand that without the -l flag to slapcat, you are > writing to > stdout instead of a file? Is it possible that is what is causing > slapcat > to crash? > I used slapcat without -l for two reasons: usually i slapcat pipiing in gzip the stdout so i can realtime gzip the ldif: slapcat -f slapd.conf | gzip > out.ldif.gz and also because on 32 bit slapcat, avoid the 2GB filsize limit on output ldif > > slapcat -f slapd.conf here the full command was: slapcat -f slapd.conf > fulldump.ldif However, I've retry with "-l file" on 32 bit linux and solaris (why not ?) Linux stops when reached 2GB file out; but there was a little bit of memory available and the allocation rate was similar to previous trials In Solaris, due to speed up the test I've ulimit -d 1024000, reached 2 GB file without stops itself (usually solaris continues, simply throws out additional data) then some time later: ch_malloc of 16392 bytes failed ch_malloc.c:57: failed assertion `0' Abort (core dumped) with a while/loop ps, last line was: PID RSS VSZ %MEM TIME STIME COMMAND 18246 1652488 1656144 41.1 31:23 09:22:35 slapcat > On my linux 2.6 system (64 bit), with a 2.5 million entry db, which > is: > > ldap00:/var/lib/ldap/slamd/64-2.5mil-db42# du -h *.bdb > 84M cn.bdb > 618M dn2id.bdb > 85M employeeNumber.bdb > 3.2G id2entry.bdb > 3.7M objectClass.bdb > 85M uid.bdb this runs I've tried a db like: ldap@labsLDAP:/TEST_producer/openldap-data> du -h *.bdb 3,0M testCode.bdb 2,9G dn2id.bdb 600M entryCSN.bdb 545M entryUUID.bdb 15G id2entry.bdb 1,9M objectClass.bdb 270M testId.bdb > So, that does mean one thing -- It definitely outgrew the 366MB of BDB > cache defined. On the other hand, once it reached its max size, it > stayed > steady there until completion was reached. > In my trials, instead, allocation never stops :( Perhaps due to a greater DB ? Paolo

1 0

Re: (ITS#4709) Insufficient permissions on PF_LOCAL sockets
by ando＠sys-net.it 14 Oct '06

14 Oct '06

Applied to HEAD; please check. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4709) Insufficient permissions on PF_LOCAL sockets
by ando＠sys-net.it 14 Oct '06

14 Oct '06

ian(a)uns.ns.ac.yu wrote: > Linux, as opposed to other *NIXes, honors PF_LOCAL socket file mode bits, so a > user must have the write permission to use the socket. OpenLDAP bind()s its > PF_LOCAL sockets without any special arrangements, so the resulting socket's > permissions are governed by the current umask. Since the umask is usually 022 or > 002, the socket ends up not being world-writable, making it unusable for users > other than root. > > Earlier OpenLDAP releases recognized a non-standard "x-mod" URL extension for > manipulating socket permissions, and the parsing code is still there, but its > results are unused. > Yes, that's been removed because non-portable and of little use. The preferred use consists in creating the socket according to umask in a directory with the desired permissions. Right now, those permissions are used to coarse grain regulate operations on a specific listener; considering their limited usefulness, their use is not recommended as that extension could be removed. It's considered experimental. > With the attached patch, PF_LOCAL sockets are always created world-writable by > setting the umask to zero before bind(). The previous umask is restored > immediately afterwards. Umask manipulation shouldn't affect PF_UNIX bind()s, so > I haven't surrounded it with #ifdef LDAP_PF_LOCAL. > Your approach seems to be sound. I'll review the patch. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4712) test007: slapd crashes
by ando＠sys-net.it 14 Oct '06

14 Oct '06

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: SuSE Linux 10.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.12.70) > > > In test007 slapd seg faults. The backtrace: > > #0 0x080dd880 in lutil_strncopy (a=0xbfde5a08 "", b=0x111 <Address 0x111 out of > bounds>, n=0) > at utils.c:303 > #1 0x08066916 in slap_cf_aux_table_unparse (src=0x819e010, bv=0xbfde6218, > tab0=0x8142180) > at config.c:1175 > #2 0x08066b68 in bindconf_free (bc=0x3) at config.c:1243 > #3 0x0805fb84 in config_replica (c=0xbfde634c) at bconfig.c:2734 > #4 0x08065cfc in config_get_vals (cf=0x81419b0, c=0xbfde634c) at config.c:449 > #5 0x08062611 in config_build_entry (op=0x8141280, rs=0xbfde634c, parent=0x0, > c=0x0, rdn=0x0, > main=0xbfde6373, extra=0x81cade0) at bconfig.c:4565 > #6 0xbfde634c in ?? () > #7 0x081794a8 in ?? () > #8 0x081794a8 in ?? () > #9 0x00000000 in ?? () > Michael, this backtrace looks weird, because: - bconfig.c:2734 is not in config_replica() in HEAD right now, and, according to cvsweb, the last commit to bconfig.c occurred 4 weeks ago (unless you modified that file yourself) - there's nothing at config.c:449 that can call config_replica(); - bindconf_free() cannot really call slap_cf_aux_table_unparse () - there's more inconsistencies... You should really cross-check what you're debugging, or something else is going berserk. Maybe try without optimization? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4708) refreshAndPersist retry parameter isn't meaningful
by ando＠sys-net.it 14 Oct '06

14 Oct '06

To me it makes a lot of sense; I've applied your patch, with minor changes, to HEAD code. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4712) test007: slapd crashes
by michael＠stroeder.com 14 Oct '06

14 Oct '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.12.70) In test007 slapd seg faults. The backtrace: #0 0x080dd880 in lutil_strncopy (a=0xbfde5a08 "", b=0x111 <Address 0x111 out of bounds>, n=0) at utils.c:303 #1 0x08066916 in slap_cf_aux_table_unparse (src=0x819e010, bv=0xbfde6218, tab0=0x8142180) at config.c:1175 #2 0x08066b68 in bindconf_free (bc=0x3) at config.c:1243 #3 0x0805fb84 in config_replica (c=0xbfde634c) at bconfig.c:2734 #4 0x08065cfc in config_get_vals (cf=0x81419b0, c=0xbfde634c) at config.c:449 #5 0x08062611 in config_build_entry (op=0x8141280, rs=0xbfde634c, parent=0x0, c=0x0, rdn=0x0, main=0xbfde6373, extra=0x81cade0) at bconfig.c:4565 #6 0xbfde634c in ?? () #7 0x081794a8 in ?? () #8 0x081794a8 in ?? () #9 0x00000000 in ?? ()

1 0

Re: (ITS#4711) back-meta search fails to stop on "@" action
by ando＠sys-net.it 14 Oct '06

14 Oct '06

rici(a)ricilake.net wrote: > Full_Name: Rici Lake > Version: 2.3.21 > OS: various > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.106.32.142) > > > In servers/slapd/back-meta/search.c the function ldap_back_dn_massage is called > at line 394 (in HEAD) in the function meta_back_search_start. It then checks the > return code using a switch statement, where the default branch is to accept the > rewrite. > > However, it is checking for return codes REWRITE_REGEXEC_{UNWILLING, ERR} while > ldap_back_dn_massage is returning actual LDAP error codes > (LDAP_UNWILLING_TO_PERFORM, LDAP_OTHER). > > Consequently, the "@" action is not honoured, and neither is any other return > code inserted with a "U" action. > Good spot. I'll fix this in minutes. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4702) out-of-memory on huge DB ?
by quanah＠stanford.edu 13 Oct '06

13 Oct '06

--On Friday, October 13, 2006 1:57 PM +0000 Paolo.Rossi.con(a)h3g.it wrote: >> No. As I already mentioned, there is no reason for slapcat to use >> large amounts of RAM, it should use whatever size your BDB cache is >> configured for and that's about it. It's possible there is a memory >> leak, but since no such leak appears under Linux that would point >> to either the Solaris C library or some other library specific to >> your platform. > > Today I've finished a cross test on a suse 10.0 linux > > Athlon XP 2200+ 768MB RAM + 1GB swap > > > > loaded huge db with same config, shared mem and set_cachesize 0 > 384000000 1 > > slapcat -f slapd.conf So you understand that without the -l flag to slapcat, you are writing to stdout instead of a file? Is it possible that is what is causing slapcat to crash? On my linux 2.6 system (64 bit), with a 2.5 million entry db, which is: ldap00:/var/lib/ldap/slamd/64-2.5mil-db42# du -h *.bdb 84M cn.bdb 618M dn2id.bdb 85M employeeNumber.bdb 3.2G id2entry.bdb 3.7M objectClass.bdb 85M uid.bdb DB_CONFIG is: set_cachesize 0 384000000 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lg_dir /var/log/bdb/slamd/64-2.5mil set_lk_max_locks 3000 # # Automatically remove log files that are no longer needed. set_flags DB_LOG_AUTOREMOVE #set_flags DB_DIRECT_DB # # Setting set_tas_spins reduces resource contention from multiple clients on systems with multiple CPU's. set_tas_spins 1 Using slapcat -l ldif_file, I then ran a while (1) loop to check the OSS and RSS sizes of slapcat. It reached the following size fairly quickly: RSS VSZ 1159740 1191916 and then never grew past that. This means the resident memory maxed out at 1.1 GB, and the virtual memory maxed out at 1.1GB as well. So, that does mean one thing -- It definitely outgrew the 366MB of BDB cache defined. On the other hand, once it reached its max size, it stayed steady there until completion was reached. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4711) back-meta search fails to stop on "@" action
by rici＠ricilake.net 13 Oct '06

13 Oct '06

Full_Name: Rici Lake Version: 2.3.21 OS: various URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.106.32.142) In servers/slapd/back-meta/search.c the function ldap_back_dn_massage is called at line 394 (in HEAD) in the function meta_back_search_start. It then checks the return code using a switch statement, where the default branch is to accept the rewrite. However, it is checking for return codes REWRITE_REGEXEC_{UNWILLING, ERR} while ldap_back_dn_massage is returning actual LDAP error codes (LDAP_UNWILLING_TO_PERFORM, LDAP_OTHER). Consequently, the "@" action is not honoured, and neither is any other return code inserted with a "U" action.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs