openldap-bugs October 2006

openldap-bugs@openldap.org

31 participants
137 discussions

(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

Re: (ITS#4702) out-of-memory on huge DB ?
by hyc＠symas.com 08 Oct '06

08 Oct '06

Paolo Rossi wrote: > >> PS: 4GB of RAM is probably not enough for a 20GB database, you won't >> be able to configure caches large enough to get decent search >> performance. I think 8GB would be a practical minimum here. >> > > This is also my opinion, for good performances are not sufficient, but > now the question is: > 4GB are not enough to anyway, to run (slowly) similar huge server > without coredump? > > p.s. or maybe I missed something, somewhere... :P > What is your entry cache size? I suggest you set it to something small, like 100, during the slapcat test. -- -- 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#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it 08 Oct '06

08 Oct '06

> 4GB is the memory limit on 32-bit Solaris, IIRC. Just like it is > 2GB on 32-bit linux. Try building everything 64-bit. I'll give a check. > Another thing to try, from when I ran my servers on Solaris, is to > fix the limits in /etc/system for the maximum amount of memory that > can be allocated. I vaguely recall having to do this for my > Solaris systems. uhm, maybe you referred "data seg size" ? now, is set to "unlimited" now I'm trying with ulimit -d 1024000, but now slapd have reached 1106MB > Oh, and with BDB on Solaris, you want to use the "shm_key" flag in > slapd.conf to use shared memory segments, when running on SPARC. > Here's the last portions of /etc/system on my old Solaris LDAP > servers: > > * turn off executable stacks > set noexec_user_stack = 1 > set noexec_user_stack_log = 1 > * increase the size of the kernel stack to 24k for Solaris 8/64-bit > set rpcmod:svc_default_stksize=0x6000 > set lwp_default_stksize=0x6000 > * force load the shared module kernel information. > forceload: sys/shmsys > * allow shared memory segments of up to 3 GB (default 1MB) > * See http://www.sun.com/sun-on-net/itworld/UIR960101perf.html > set shmsys:shminfo_shmmax=3221225472 > * Increase memory performance when filesystem is being heavily used. > * See http://www.sun.com/sun-on-net/performance/priority_paging.html > set priority_paging=1 > * Increase memory performance when filesystem is being heavily used. > * See http://www.samag.com/documents/s=1323/sam0110e/0110e.htm > set maxpgio=25468 > set slowscan=500 > * autoup influences how much RAM is checked by fsflush every 5 > seconds. > * Default = 30. Increase autoup to decrease mem management overhead. > * See http://docs.sun.com/db/doc/806-7009/6jftnqsin?a=view > set autoup = 60 > * Up tcp conn hash size. Defaults to 256. > * See http://www.deny-all.com/en/solsecu/tech/tuning.html > set tcp:tcp_conn_hash_size = 16384 > * Up file descriptor limit. Defaults to 1024. > set rlim_fd_max = 16384 > This is mine: set shmsys:shminfo_shmmax=2147483648 set shmsys:shminfo_shmmin=100 set shmsys:shminfo_shmmni=100 set shmsys:shminfo_shmseg=100 set semsys:seminfo_semmap=64 set semsys:seminfo_semmni=4096 set semsys:seminfo_semmns=4096 set semsys:seminfo_semmnu=4096 set semsys:seminfo_semume=64 set semsys:seminfo_semmsl=100 Thx for details, I will cross check if I miss somethings Paolo Rossi

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

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 October 2006