openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

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

11 Oct '06

Quanah Gibson-Mount wrote: > 4GB is the memory limit on 32-bit Solaris, IIRC. Just like it is > 2GB on 32-bit linux. Try building everything 64-bit. Hello again. Today I've rebuilt everything 64-bit To have a "fast shot", I've load a 1m dn, then I've ulimit -d 96304 the data memory for user. After a some minutes slapcat: slapcat -f openldap/slapd.conf |gzip > delete-me.ldif ch_malloc of 16396 bytes failed Assertion failed: 0, file ch_malloc.c, line 57 Abort (core dumped) and a second try: slapcat -f openldap/slapd.conf > delete-me.ldif bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered. ch_malloc of 16396 bytes failed Assertion failed: 0, file ch_malloc.c, line 57 Abort (core dumped) at crash moment, with top: size=180M res=176M Now, the question: Huge LDAP only possible with big RAM ? :D Other ideas? :/ Paolo

1 0

(ITS#4707) patch: option to bind client socket to an address
by rtsai＠ironport.com 10 Oct '06

10 Oct '06

Full_Name: Robert Tsai Version: 2.3.27 OS: FreeBSD 6.1-RELEASE URL: ftp://ftp.openldap.org/incoming/openldap-2.3.27-bindaddr.patch.txt Submission from: (NULL) (63.251.108.100) This is a patch that provides a mechanism to bind the LDAP client connection to a desired address via ldap_set_option(..., LDAP_OPT_BINDADDR). This call saves some state which is then used by ldap_int_prepare_socket to bind the socket before opening a connection to the LDAP server.

1 0

(ITS#4706) regex.h on Solaris 10 sparc
by stew.redfield＠gmail.com 10 Oct '06

10 Oct '06

Full_Name: Stew Redfield Version: 2.3.27 OS: Solaris 10 sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.219.72.58) /configure --prefix=/usr/local --snip-- checking regex.h presence... yes configure: WARNING: regex.h: present but cannot be compiled configure: WARNING: regex.h: check for missing prerequisite headers? configure: WARNING: regex.h: see the Autoconf documentation configure: WARNING: regex.h: section "Present But Cannot Be Compiled" configure: WARNING: regex.h: proceeding with the preprocessor's result configure: WARNING: regex.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for regex.h... yes checking for library containing regfree... none required checking for compatible POSIX regex... no configure: error: broken POSIX regex!

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 09 Oct '06

09 Oct '06

--On Sunday, October 08, 2006 11:36 AM +0000 openldap-its(a)OpenLDAP.org wrote: I did some testing, and found that the problem is that accesslog is creating a new contextCSN every time slapd is started. Here's my testing: (a) Search accesslog for its contextCSN: ldap-test0:/tmp# cat contextCSN.before dn: cn=accesslog contextCSN: 20061009111121Z#000000#00#000000 (b) Stop slapd, dump the accesslog DB to LDIF, look at the entry values: ldap-test0:/tmp# cat contextCSN.LDIF dn: cn=accesslog objectClass: auditContainer cn: accesslog entryCSN: 20060829205636Z#000000#00#000000 structuralObjectClass: auditContainer contextCSN: 20061009111121Z#000000#00#000000 (c) Start slapd, query accesslog for its contextCSN: ldap-test0:/tmp# cat contextCSN.startup dn: cn=accesslog contextCSN: 20061009183449Z#000000#00#000000 As you can see, a new version was generated at startup, rather than it keeping the one it had at shutdown. Why, I don't know. Then, I did the following: (a) stop slapd (b) remove the current accesslog db (since all slaves are in sync) (c) get the contextCSN: dn: cn=accesslog contextCSN: 20061009183830Z#000000#00#000000 (d) stopped slapd (e) started slapd (f) queried, the contextCSN is the same(?!!) ldap-test0:~> ldapsearch -LLL -Q -h localhost -b cn=accesslog -s base contextCSN dn: cn=accesslog contextCSN: 20061009183830Z#000000#00#000000 (g) Made a modification (h) got the current contectCSN: dn: cn=accesslog contextCSN: 20061009184042Z#000000#00#000000 (i) Stopped slapd (j) restarted slapd (k) got the contectCSN: dn: cn=accesslog contextCSN: 20061009184042Z#000000#00#000000 It is the same again. So at best guess, something "corrupted" the accesslog DB somehow? I'm not really sure. I will monitor to see if I get back into the same situation again. --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#4705) 11866 Segmentation fault (core dumped)
by michael＠stroeder.com 09 Oct '06

09 Oct '06

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: > > configured with BDB 4.2 (+ patches) as > > ./configure \ > --enable-modules \ > --enable-dynamic \ > --enable-backends=mod \ > --enable-overlays=mod \ > --enable-perl=no This minimalistic configure does not even compile on my system. > passes all tests I think this error has something to do with the solution for ITS#4671. > Note that I typically use "make distclean" to regenerate things. This also does not work. See my current build script below. Ciao, Michael. --------------------------------- snip --------------------------------- . /home/michael/src/build-env-openldap #export CFLAGS="-g -O4 -march=pentium4" export CFLAGS="-g -O2" export CPPFLAGS="-I/usr/include/heimdal -I/usr/include/sasl -I${BDB}/include -I${SASL}/include -I${HEIMDAL}/include" export LDFLAGS="-L${BDB}/lib -L${SASL}/lib -L${HEIMDAL}/lib -R${BDB}/lib -R${SASL}/lib -R${HEIMDAL}/lib" export LD_LIBRARY_PATH="${BDB}/lib:${SASL}/lib:${HEIMDAL}/lib" # Disable test036-meta-concurrency since it always hangs export TEST_META=no PWD=`pwd` DIRNAME=`dirname ${PWD}` PREFIX=/opt/`basename ${DIRNAME}` echo "PREFIX="${PREFIX} make distclean ./configure \ --enable-dynamic \ --enable-modules=yes \ --enable-backends=mod \ --enable-overlays=mod \ --enable-aci=yes \ --enable-cleartext \ --enable-crypt=yes \ --enable-debug=yes \ --enable-kpasswd=yes \ --enable-lmpasswd=yes \ --enable-rewrite=yes \ --enable-rlookups=yes \ --enable-slapi=yes \ --enable-slp=yes \ --enable-spasswd=yes \ --enable-wrappers=no \ --prefix=${PREFIX} \ --with-cyrus-sasl=yes \ --with-kerberos=yes \ --with-readline=yes \ --with-threads=yes \ --with-tls=yes make && make test

1 0

Re: (ITS#4705) 11866 Segmentation fault (core dumped)
by ando＠sys-net.it 08 Oct '06

08 Oct '06

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD (synced now!) > OS: SuSE Linux 10.1 > URL: > Submission from: (NULL) (83.124.30.52) > > > Configured and compiled from scratch after 'make veryclean'. > > $ ./run test000 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test000-rootdse... > running defines.sh > Starting slapd on TCP/IP port 9011... > ./scripts/test000-rootdse: line 31: 11951 Segmentation fault (core dumped) > $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > [..] > > ------------------------------------------------------------------------------------- > (gdb) bt > #0 monitor_subsys_backend_init (be=0x0, ms=0xb78f1840) at backend.c:69 > #1 0xb78e3bde in monitor_back_db_open (be=0x81df950) at init.c:2214 > #2 0x0807badf in backend_startup_one (be=0x81df950) at backend.c:212 > #3 0x0807bd73 in backend_startup (be=0x81df950) at backend.c:303 > #4 0x0805e983 in main (argc=8, argv=0xbfa39d14) at main.c:917 > > > configured with BDB 4.2 (+ patches) as ./configure \ --enable-modules \ --enable-dynamic \ --enable-backends=mod \ --enable-overlays=mod \ --enable-perl=no passes all tests (I had some problems because I seldom use modules, and I forgot --enable-dynamic). Can you point out any relevant difference? Note that I typically use "make distclean" to regenerate things. I don't know the detailed difference between distclean and veryclean, but distclean seems to depend on veryclean so it could do something more. In any case, distclean requires to re-configure before building. 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#4705) 11866 Segmentation fault (core dumped)
by michael＠stroeder.com 08 Oct '06

08 Oct '06

Full_Name: Michael Ströder Version: HEAD (synced now!) OS: SuSE Linux 10.1 URL: Submission from: (NULL) (83.124.30.52) Configured and compiled from scratch after 'make veryclean'. $ ./run test000 Cleaning up test run directory leftover from previous run. Running ./scripts/test000-rootdse... running defines.sh Starting slapd on TCP/IP port 9011... ./scripts/test000-rootdse: line 31: 11951 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... [..] ------------------------------------------------------------------------------------- (gdb) bt #0 monitor_subsys_backend_init (be=0x0, ms=0xb78f1840) at backend.c:69 #1 0xb78e3bde in monitor_back_db_open (be=0x81df950) at init.c:2214 #2 0x0807badf in backend_startup_one (be=0x81df950) at backend.c:212 #3 0x0807bd73 in backend_startup (be=0x81df950) at backend.c:303 #4 0x0805e983 in main (argc=8, argv=0xbfa39d14) at main.c:917

1 0

Re: authz-regexp matches twice on same dse (ITS#4698)
by ap＠d-dt.de 08 Oct '06

08 Oct '06

Pierangelo Masarati wrote: >> Pierangelo Masarati wrote: >> > What authz-regexp does is run an internal search. If the search returns > exactly one entry, then there's no way it can be, say, returned twice, > otherwise it would also when running aregular search. Moreover, I've > recrated you scenario in 2.3.27 and HEAD, and everything seems to work as > expected in all cases. I suspect something else is wrong, for example > data in your DB is not like it appears. The objects used actually were 'person's with auxiliary 'posixAccount' and 'organizationalRoles' on the other side. I also installed a clean directory and at least I must agree with you, that the problem is caused somewhere else: After I dumped and reloaded data with slapcat/slapadd into bdb it finally works as expected. Thanks for verifing and sorry for the inconvenience caused. A --

1 0

(ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 08 Oct '06

08 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27 OS: Linux 2.6 kernel URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) I recently set up a script to monitor whether or not my replicas are in sync with the master. I've found that since my master shuts down nightly, this triggers a bug in accesslog where it fails to store its current contextCSN at that time. Then, when the master restarts, accesslog creates a new contextCSN that the slaves pick up, but the master's main database (dc=stanford,dc=edu) doesn't. For example: nagios1:~> /usr/lib/nagios/plugins/check_syncrepl -H ldap-uat1 CRITICAL dc=stanford,dc=edu out of sync 0 weeks 0 days 2:46:12 ahead nagios1:~> ldapsearch -LLL -Q -h ldap-uat0 -s base -b cn=accesslog contextCSN dn: cn=accesslog contextCSN: 20061008111122Z#000000#00#000000 nagios1:~> ldapsearch -LLL -Q -h ldap-uat1 -s base -b dc=stanford,dc=edu contextCSN dn: dc=stanford,dc=edu contextCSN: 20061008111122Z#000000#00#000000 nagios1:~> ldapsearch -LLL -Q -h ldap-uat0 -s base -b dc=stanford,dc=edu contextCSN dn: dc=stanford,dc=edu contextCSN: 20061008082510Z#000000#00#000000 where ldap-uat0 is my master. You can see the accesslog DB has the new contextCSN, which its pushed out to the slaves, while dc=stanford,dc=edu on the master still has the correct contextCSN. This happens in my test, uat, and prod environments, and remains this way until the environments receive their first update, after which the CSN's all get sync'd. --Quanah

1 0

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

08 Oct '06

> What is your entry cache size? I suggest you set it to something > small, like 100, during the slapcat test. It was 5000 I've tried 100 and ulimit mem at 1024000 after about 50 mins of slapcat: 1600 MB ca. MEM allocated coredump (1691966556 bytes) output ldif ca. 20% of full DB :( Paolo Rossi

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs