Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com
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/
14 years
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com
<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
14 years
(ITS#6390) test020 seg faults
by michael＠stroeder.com
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 ?? ()
14 years
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com
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/
14 years
Re: (ITS#6389) Allow setting syncrepl keepalive
by hyc＠symas.com
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/
14 years
Re: (ITS#6389) Allow setting syncrepl keepalive
by masarati＠aero.polimi.it
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.
14 years
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com
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.=
14 years
Re: (ITS#6389) Allow setting syncrepl keepalive
by hyc＠symas.com
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/
14 years
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com
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/
14 years
