[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#4811) refreshAndPersist and Monitor -> slapd core dump
Full_Name: Niels Frimodt Sørensen
Version: 2.3.32
OS: Solaris
URL:
Submission from: (NULL) (80.160.139.81)
Hi,
refreshAndPersist mode of syncrepl seems to have problems with Monitor. The
slave is dumping core when I do ldapsearch against cn=Connections, cn=Monitor.
The system is running on Solaris 9 and based on OpenLDAP 2.3.32.
Replication works just fine.
If I change syncrepl type to refreshOnly then the ldapsearch is completed
without core dump.
Further information on configuration and debug below.
The Master has the following conf:
# slapd.conf
# Schema
include /opt/ldap/content2/schema/core.schema
# Control files
pidfile /opt/ldap/backend2/var/slapd.pid
argsfile /opt/ldap/backend2/var/slapd.args
database bdb
suffix "c=NO"
rootdn "cn=Manager,c=NO"
rootpw Test1234
directory /opt/ldap/content2/data
checkpoint 128 10
# Indices to maintain
index objectclass,entryCSN,entryUUID eq
index serialNumber pres,eq
index mail pres,eq
index cn pres,eq
cachesize 100000
threads 64
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
database monitor
The slave has the following conf:
# slapd.conf
# Schema
include /opt/ldap/content-buslave/schema/core.schema
# Control files
pidfile /opt/ldap/backend-buslave/var/slapd.pid
argsfile /opt/ldap/backend-buslave/var/slapd.args
# database defs
database bdb
suffix "c=NO"
rootdn "cn=Manager,c=NO"
rootpw Test1234
directory /opt/ldap/content-buslave/data
checkpoint 128 10
# Indices to maintain
index objectclass,entryCSN,entryUUID eq
index serialNumber pres,eq
index mail pres,eq
index cn pres,eq
cachesize 100000
threads 32
syncrepl rid=123
provider=ldap://127.0.0.1:3892
type=refreshAndPersist
searchbase="c=NO"
filter="(objectClass=*)"
scobe=sub
attrs=""
schemachecking=off
bindmethod=simple
updatedn="cn=Manager,c=NO"
binddn="cn=Manager,c=NO"
credentials="Test1234"
database monitor
The ldapsearch output that indicate the problem:
ldapsearch -h localhost -p 3891 -b "cn=Monitor" "cn=Connections" +
# extended LDIF
#
# LDAPv3
# base <cn=Monitor> with scope subtree
# filter: cn=Connections
# requesting: +
#
# Connections, Monitor
dn: cn=Connections,cn=Monitor
structuralObjectClass: monitorContainer
creatorsName:
modifiersName:
createTimestamp: 20070122103402Z
modifyTimestamp: 20070122103402Z
entryDN: cn=Connections,cn=Monitor
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
ldap_result: Can't contact LDAP server (-1)
The slave debugs the following during the search:
...
=> test_filter
EQUALITY
=> access_allowed: search access to "cn=Connections,cn=Monitor" "cn" requested
=> access_allowed: backend default search access granted to "(anonymous)"
<= test_filter 6
=> send_search_entry: conn 0 dn="cn=Connections,cn=Monitor"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "entry" requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor"
"structuralObjectClass" requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "creatorsName"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "modifiersName"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "createTimestamp"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "modifyTimestamp"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "entryDN"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor"
"subschemaSubentry" requested
=> access_allowed: backend default read access granted to "(anonymous)"
=> access_allowed: read access to "cn=Connections,cn=Monitor" "hasSubordinates"
requested
=> access_allowed: backend default read access granted to "(anonymous)"
ber_flush: 308 bytes to sd 13
0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn=
0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M
0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st
0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl
0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo
0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat
0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m
0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1...
0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest
0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221
00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify
00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200
00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&..
00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co
00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon
00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem
0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn=
0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has
0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1...
0130: 54 52 55 45 TRUE
ldap_write: want=308, written=308
0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn=
0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M
0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st
0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl
0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo
0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat
0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m
0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1...
0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest
0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221
00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify
00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200
00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&..
00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co
00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon
00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem
0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn=
0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has
0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1...
0130: 54 52 55 45 TRUE
conn=0 op=1 ENTRY dn="cn=connections,cn=monitor"
<= send_search_entry: conn 0 exit.
Segmentation Fault - core dumped
--
Venlig hilsen/Kind regards
Niels Frimodt Sørensen
Signaturgruppen A/S
www.signaturgruppen.dk