[Date Prev][Date Next] [Chronological] [Thread] [Top]

refreshAndPersist and Monitor -> slapd core dump

To: openldap-software@openldap.org
Subject: refreshAndPersist and Monitor -> slapd core dump
From: Niels Frimodt Sørensen <niels@signaturgruppen.dk>
Date: Mon, 22 Jan 2007 12:01:28 +0100
User-agent: Thunderbird 1.5.0.7 (Windows/20060909)

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

Follow-Ups:
- Re: refreshAndPersist and Monitor -> slapd core dump
  - From: Pierangelo Masarati <ando@sys-net.it>

Prev by Date: Re: OpenLDAP issues when connecting over SSL
Next by Date: Re: slurpd access control problems
Index(es):
- Chronological
- Thread