refreshAndPersist and Monitor -> slapd core dump - openldap-software

22 Jan 2007


      Hi,
I am testing refreshAndPersist mode of syncrepl and would like to use 
Monitor. The slave is however 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.
What am I doing wrong?
-- 

Venlig hilsen/Kind regards

Niels Frimodt Sørensen

Signaturgruppen A/S
www.signaturgruppen.dk


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