(ITS#4706) regex.h on Solaris 10 sparc
by stew.redfield＠gmail.com
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!
17 years, 1 month
Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu
--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
17 years, 1 month
Re: (ITS#4705) 11866 Segmentation fault (core dumped)
by michael＠stroeder.com
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
17 years, 1 month
Re: (ITS#4705) 11866 Segmentation fault (core dumped)
by ando＠sys-net.it
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
------------------------------------------
17 years, 1 month
(ITS#4705) 11866 Segmentation fault (core dumped)
by michael＠stroeder.com
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
17 years, 1 month
Re: authz-regexp matches twice on same dse (ITS#4698)
by ap＠d-dt.de
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
--
17 years, 1 month
(ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu
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
17 years, 1 month
Re: (ITS#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it
> 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
17 years, 1 month
Re: (ITS#4702) out-of-memory on huge DB ?
by hyc＠symas.com
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/
17 years, 1 month
Re: (ITS#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it
> 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
17 years, 1 month
