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
-
niels＠signaturgruppen.dk