openldap-bugs November 2009

openldap-bugs@openldap.org

40 participants
183 discussions

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 19 Nov '09

19 Nov '09

Peter Palmreuther wrote: > <hyc(a)symas.com> wrote: >> Peter Palmreuther wrote: >>> Sorry, misconfiguration on my side when I replicated the real setup at my home server. >>> I'fe corrected configuration and rerun test. >> >> Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be >> testing the RE24 code now, not 2.4.19.) > > I've checked out HEAD from CVSROOT > ':pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP' and ran several > thousand test iterations without a single failure yet. > So I'd guess it seems to be fixed. > > How to continue best, getting a version ready for production? I > hesitate to simply compile HEAD for productive use, as I can't make > sure there's no change between latest stable / release and HEAD that > could lead to other trouble ... > Is this fix "back-portable" to 2.4.19 source, so I can compile a > 2.4.19-custom version??? > > Thanks in advance, The patch will be in 2.4.20, which will be released soon. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 19 Nov '09

19 Nov '09

<hyc(a)symas.com> wrote: > Peter Palmreuther wrote: >> Sorry, misconfiguration on my side when I replicated the real setup at my home server. >> I'fe corrected configuration and rerun test. > > Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be > testing the RE24 code now, not 2.4.19.) I've checked out HEAD from CVSROOT ':pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP' and ran several thousand test iterations without a single failure yet. So I'd guess it seems to be fixed. How to continue best, getting a version ready for production? I hesitate to simply compile HEAD for productive use, as I can't make sure there's no change between latest stable / release and HEAD that could lead to other trouble ... Is this fix "back-portable" to 2.4.19 source, so I can compile a 2.4.19-custom version??? Thanks in advance, -- Regards, Peter

1 0

(ITS#6390) test020 seg faults
by michael＠stroeder.com 19 Nov '09

19 Nov '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.84.65) Relevant build options: CFLAGS="-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER -DDEVEL" $ gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.4 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) Core was generated by `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/lt-'. Program terminated with signal 11, Segmentation fault. #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 (gdb) info threads 9 Thread 20130 0x00002b4694de831e in ?? () from /lib64/libc.so.6 8 Thread 20146 0x00002b4694de831e in ?? () from /lib64/libc.so.6 7 Thread 20083 0x00002b4694de831e in ?? () from /lib64/libc.so.6 6 Thread 20162 0x00002b4694dd4712 in select () from /lib64/libc.so.6 5 Thread 20082 0x00002b4694ddb7f8 in epoll_wait () from /lib64/libc.so.6 4 Thread 20240 0x00002b4693888049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 20067 0x00002b469388496d in pthread_join () from /lib64/libpthread.so.0 2 Thread 20178 0x00002b4694dcde7b in write () from /lib64/libc.so.6 * 1 Thread 20194 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 9 (Thread 20130): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697431988 in ?? () #5 0x0000000000aa1470 in ?? () #6 0x00002b469967d730 in ?? () #7 0x00002b469967d7c0 in ?? () #8 0x00002b469967d640 in ?? () #9 0x000000000099753a in ?? () #10 0x09802b469967d6f0 in ?? () #11 0x0000000000997538 in ?? () #12 0x000000240000001e in ?? () #13 0x0000000000000024 in ?? () #14 0x0000000000000000 in ?? () Thread 8 (Thread 20146): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697431988 in ?? () #5 0x0000000000bad820 in ?? () #6 0x00002b4699e7e730 in ?? () #7 0x00002b4699e7e7c0 in ?? () #8 0x00002b4699e7e640 in ?? () #9 0x0000000000aa2812 in ?? () #10 0x09802b4699e7e6f0 in ?? () #11 0x0000000000aa2810 in ?? () #12 0x000000240000001e in ?? () #13 0x0000000000000024 in ?? () #14 0x0000000000000000 in ?? () Thread 7 (Thread 20083): #0 0x00002b4694de831e in ?? () from /lib64/libc.so.6 #1 0x00002b4694d6e058 in ?? () from /lib64/libc.so.6 #2 0x00002b4694d6df32 in fputs () from /lib64/libc.so.6 #3 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #4 0x00002b4697430565 in ?? () #5 0x0000000000000000 in ?? () Thread 6 (Thread 20162): #0 0x00002b4694dd4712 in select () from /lib64/libc.so.6 #1 0x00002b4697430353 in ?? () #2 0x0000000000000000 in ?? () Thread 5 (Thread 20082): #0 0x00002b4694ddb7f8 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042ffd3 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2642 #2 0x00002b469388365d in start_thread () from /lib64/libpthread.so.0 #3 0x00002b4694ddb14d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () ---Type <return> to continue, or q <return> to quit--- Thread 4 (Thread 20240): #0 0x00002b4693888049 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b4692c72f85 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:672 #2 0x00002b469388365d in start_thread () from /lib64/libpthread.so.0 #3 0x00002b4694ddb14d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 3 (Thread 20067): #0 0x00002b469388496d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042d04c in slapd_set_write (s=<value optimized out>, wake=0) at daemon.c:962 #2 0x000000000041af37 in cfAddOverlay (p=0x2b469867e9e0, e=0x0, ca=0x4e72) at bconfig.c:4579 #3 0x0000000000000000 in ?? () Thread 2 (Thread 20178): #0 0x00002b4694dcde7b in write () from /lib64/libc.so.6 #1 0x00002b4694d78c53 in _IO_file_write () from /lib64/libc.so.6 #2 0x00002b4694d788ca in ?? () from /lib64/libc.so.6 #3 0x00002b4694d78bbe in _IO_file_xsputn () from /lib64/libc.so.6 #4 0x00002b4694d6df73 in fputs () from /lib64/libc.so.6 #5 0x00002b4692eb5f28 in lutil_debug (debug=<value optimized out>, level=<value optimized out>, fmt=<value optimized out>) at debug.c:72 #6 0x00002b4697420e45 in ?? () #7 0x00002b469ae80b50 in ?? () #8 0x00002b469ae808f0 in ?? () #9 0x0000000000000100 in ?? () #10 0x0000000000000000 in ?? () Thread 1 (Thread 20194): #0 0x00002b4694d8ef54 in memrchr () from /lib64/libc.so.6 #1 0x000000000048e304 in syncrepl_add_glue (op=0x2b469b681e10, e=0x817aa8) at syncrepl.c:2889 #2 0x00002b4697aa4b93 in ?? () #3 0x00002b469b682024 in ?? () #4 0x00002b469b681d2f in ?? () #5 0x00002b46ffffffff in ?? () #6 0x00002b469b683c20 in ?? () #7 0x00002b469b682490 in ?? () #8 0x00002b469505e460 in ?? () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? ()

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 19 Nov '09

19 Nov '09

Peter Palmreuther wrote: > Sorry, misconfiguration on my side when I replicated the real setup at my home server. > I'fe corrected configuration and rerun test. Thanks. Please try the syncprov.c in CVS HEAD. (Also you should probably be testing the RE24 code now, not 2.4.19.) > 'debug-03' is put on known URL, server configuration is > > , [ server #1 {egrep -v '^(#|\s*$)' slapd.conf} ] > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/openldap.schema > include /usr/local/etc/openldap/schema/java.schema > include /usr/local/etc/openldap/schema/samba.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/dhcp.schema > pidfile /home/pit/esolution/ldap1/run/slapd.pid > argsfile /home/pit/esolution/ldap1/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_bdb > moduleload back_monitor > moduleload back_hdb > access to dn.subtree="o=esolution,dc=deutscherv,dc=de" > by dn.exact="cn=Admin,o=esolution,dc=deutscherv,dc=de" manage > by dn.exact="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" read > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous auth > access to dn.subtree="dc=deutscherv,dc=de" > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous auth > access to * > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by self write > by users read > by anonymous auth > database hdb > suffix "dc=deutscherv,dc=de" > directory /home/pit/esolution/ldap1/data/deutscherv.de > rootdn "cn=Admin,dc=deutscherv,dc=de" > rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl > index objectClass eq > index entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > syncrepl rid=001 > provider=ldap://localhost:11389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="5 +" > serverID 1 > mirrormode on > database monitor > ` > > , [ server #2 {egrep -v '^(#|\s*$)' slapd.conf} ] > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/openldap.schema > include /usr/local/etc/openldap/schema/java.schema > include /usr/local/etc/openldap/schema/samba.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/dhcp.schema > pidfile /home/pit/esolution/ldap2/run/slapd.pid > argsfile /home/pit/esolution/ldap2/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_bdb > moduleload back_monitor > moduleload back_hdb > access to dn.subtree="o=esolution,dc=deutscherv,dc=de" > by dn.exact="cn=Admin,o=esolution,dc=deutscherv,dc=de" manage > by dn.exact="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" read > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous read > access to dn.subtree="dc=deutscherv,dc=de" > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by anonymous read > access to * > by dn.exact="cn=Admin,dc=deutscherv,dc=de" manage > by self write > by users read > by anonymous auth > database hdb > suffix "dc=deutscherv,dc=de" > directory /home/pit/esolution/ldap2/data/deutscherv.de > rootdn "cn=Admin,dc=deutscherv,dc=de" > rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl > index objectClass eq > index entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > syncrepl rid=001 > provider=ldap://localhost:10389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="5 +" > serverID 2 > mirrormode on > database monitor > ` -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6389) Allow setting syncrepl keepalive
by hyc＠symas.com 19 Nov '09

19 Nov '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> This is low priority. Few platforms provide support for >> process/socket-specific keepalive settings. Usually you just set it >> system-wide in the kernel. (Note that a single setting is insufficient, there >> are 3 parameters that need to be set in concert.) > > I suggest moving this info into the slap_bindconf structure, to allow > its exploitation anywhere connections need to be set up, and defining a > syntax like keepalive="[<idle>]:[<probe>]:[<intervals>]". An empty > value would mean use the default. Sounds OK. Ultimately we should consider moving syncrepl into its own config entry. Perhaps for 2.5. Not sure if that affects slap_bindconf or not; that still seems to be useful in its current form. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6389) Allow setting syncrepl keepalive
by masarati＠aero.polimi.it 19 Nov '09

19 Nov '09

hyc(a)symas.com wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.19 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.131.62.113) > >> When configuring a replica using syncrepl, it should be possible to have an >> option that sets the keepalive used for the tcp connection between the replica >> and master. Support for this was added to libldap, but no corresponding support >> was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for >> configuring this, based in seconds. > > This is low priority. Few platforms provide support for > process/socket-specific keepalive settings. Usually you just set it > system-wide in the kernel. (Note that a single setting is insufficient, there > are 3 parameters that need to be set in concert.) I suggest moving this info into the slap_bindconf structure, to allow its exploitation anywhere connections need to be set up, and defining a syntax like keepalive="[<idle>]:[<probe>]:[<intervals>]". An empty value would mean use the default. p.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 19 Nov '09

19 Nov '09

hyc(a)symas.com wrote: > Peter Palmreuther wrote: >> I modified slapd.conf to contain 'retry=3D"5 +"' instead of a 60 = second >> timeout. >>=20 >> I started both servers and checked "do_syncrepl" in server #1 was = followed >> by log information stating it connected to server #2. >>=20 >> I then rerun the test and this time it did not that much iterations, = but >> failed during the first run (with each run being 100 round of "add, = mod, >> delete"). >>=20 >> The URL with new log output is still the same, it's the = "debug-02.tar.*" >> files. >=20 > In both the new and old logs, the 2nd server is sending updates back = to the > first server. This can only happen if the serverID is misconfigured. = Please > post your slapd configs for both servers. Sorry, misconfiguration on my side when I replicated the real setup at = my home server. I'fe corrected configuration and rerun test. 'debug-03' is put on known URL, server configuration is ,=97=97=97=97=97 [ server #1 {egrep -v '^(#|\s*$)' slapd.conf} ] = =97=97=97=97=97=97=97=97=97 include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/dhcp.schema pidfile /home/pit/esolution/ldap1/run/slapd.pid argsfile /home/pit/esolution/ldap1/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_bdb moduleload back_monitor moduleload back_hdb access to dn.subtree=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,o=3Desolution,dc=3Ddeutscherv,dc=3Dde" = manage by dn.exact=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc=3D= de" read by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous auth access to dn.subtree=3D"dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous auth access to * by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by self write by users read by anonymous auth database hdb suffix "dc=3Ddeutscherv,dc=3Dde" directory /home/pit/esolution/ldap1/data/deutscherv.de rootdn "cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl index objectClass eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=3D001 provider=3Dldap://localhost:11389 type=3DrefreshAndPersist searchbase=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" schemachecking=3Don bindmethod=3Dsimple binddn=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc= =3Dde" credentials=3D"M1rr0rM3" retry=3D"5 +" serverID 1 mirrormode on database monitor `=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97 ,=97=97=97=97=97 [ server #2 {egrep -v '^(#|\s*$)' slapd.conf} ] = =97=97=97=97=97=97=97=97=97 include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/dhcp.schema pidfile /home/pit/esolution/ldap2/run/slapd.pid argsfile /home/pit/esolution/ldap2/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_bdb moduleload back_monitor moduleload back_hdb access to dn.subtree=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,o=3Desolution,dc=3Ddeutscherv,dc=3Dde" = manage by dn.exact=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc=3D= de" read by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous read access to dn.subtree=3D"dc=3Ddeutscherv,dc=3Dde" by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by anonymous read access to * by dn.exact=3D"cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" manage by self write by users read by anonymous auth database hdb suffix "dc=3Ddeutscherv,dc=3Dde" directory /home/pit/esolution/ldap2/data/deutscherv.de rootdn "cn=3DAdmin,dc=3Ddeutscherv,dc=3Dde" rootpw {SSHA}kFujMZAoRiNkD6tlvVB/Ffj5zNsLXBpl index objectClass eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=3D001 provider=3Dldap://localhost:10389 type=3DrefreshAndPersist searchbase=3D"o=3Desolution,dc=3Ddeutscherv,dc=3Dde" schemachecking=3Don bindmethod=3Dsimple binddn=3D"cn=3DMirrorMode,o=3Desolution,dc=3Ddeutscherv,dc= =3Dde" credentials=3D"M1rr0rM3" retry=3D"5 +" serverID 2 mirrormode on database monitor `=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97 --=20 Regards, Peter.=

1 0

Re: (ITS#6389) Allow setting syncrepl keepalive
by hyc＠symas.com 18 Nov '09

18 Nov '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.19 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.131.62.113) > When configuring a replica using syncrepl, it should be possible to have an > option that sets the keepalive used for the tcp connection between the replica > and master. Support for this was added to libldap, but no corresponding support > was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for > configuring this, based in seconds. This is low priority. Few platforms provide support for process/socket-specific keepalive settings. Usually you just set it system-wide in the kernel. (Note that a single setting is insufficient, there are 3 parameters that need to be set in concert.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 18 Nov '09

18 Nov '09

Peter Palmreuther wrote: > I modified slapd.conf to contain 'retry="5 +"' instead of a 60 second > timeout. > > I started both servers and checked "do_syncrepl" in server #1 was followed > by log information stating it connected to server #2. > > I then rerun the test and this time it did not that much iterations, but > failed during the first run (with each run being 100 round of "add, mod, > delete"). > > The URL with new log output is still the same, it's the "debug-02.tar.*" > files. In both the new and old logs, the 2nd server is sending updates back to the first server. This can only happen if the serverID is misconfigured. Please post your slapd configs for both servers. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 18 Nov '09

18 Nov '09

CVS HEAD, including the two changes related to assertions (the change = log references ITS#6361), may fix this issue. I have been running the = new slapd for over 24 hours with no problems. This is much longer than = slapd would run for me before the new code.=

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2009