I looked but couldn&#39;t find a match to this issue, so was wondering if anyone else has seen something like it or can tell what might be wrong in my configuration.  Thanks in advance!<br><br>I&#39;m using OpenLDAP version 2.4.21-47.1 (here is the relevant output from &quot;rpm -qa | grep ldap&quot; on my server):<br>
<br>openldap2-client-2.4.21-51.1<br>openldap2-2.4.21-47.1<br>openldap2-back-meta-2.4.21-51.1<br><br>I&#39;m trying to get Multi-master replication working between 2 servers.  In my testing, I have discovered that when I try to reset the server (remove the configuration and start again) it crashes when trying to remove the olcOverlay={0}syncprov,olcDatabase={0}config,cn=config entry in the cn=config tree.  I attached a screen shot of the output from tracing with slapd -d -1 when the fault happened in the attached file called <b>segFaultOutput.bmp.</b><br>
<br>If I restart the server, I can run the test again (which configures the olcOverlay={0}syncprov entry and then removes it) and it will work the first time, but if I run it a second time it will crash. <br><br>Here is the configuration from the ldif files in /etc/openldap/slapd.d<br>
<br><b>cn=config.ldif:</b><br><br>dn: cn=config<br>objectClass: olcGlobal<br>cn: config<br>structuralObjectClass: olcGlobal<br>entryUUID: 8d35d270-286b-102f-998d-8313efe688a2<br>creatorsName: cn=config<br>createTimestamp: 20100720165657Z<br>
entryCSN: 20100720165733.055688Z#000000#00c#000000<br>modifiersName: cn=manager,cn=config<br>modifyTimestamp: 20100720165733Z<br>contextCSN: 20100720165732.317584Z#000000#000#000000<br>contextCSN: 20100720165733.125549Z#000000#00c#000000<br>
<br><br><b>cn=schema.ldif</b>:<br><br>dn: cn=schema<br>objectClass: olcSchemaConfig<br>cn: schema<br>structuralObjectClass: olcSchemaConfig<br>entryUUID: 8d35e49a-286b-102f-998e-8313efe688a2<br>creatorsName: cn=config<br>
createTimestamp: 20100720165657Z<br>entryCSN: 20100720165657.613177Z#000000#000#000000<br>modifiersName: cn=config<br>modifyTimestamp: 20100720165657Z<br><br><br><b>olcDatabase={0}config.ldif</b>:<br><br>dn: olcDatabase={0}config<br>
objectClass: olcDatabaseConfig<br>olcDatabase: {0}config<br>olcAccess: {0}to * by * none<br>olcRootDN: cn=manager,cn=config<br>olcRootPW:: Y29uZmln<br>structuralObjectClass: olcDatabaseConfig<br>entryUUID: 8d37bc20-286b-102f-9993-8313efe688a2<br>
creatorsName: cn=config<br>createTimestamp: 20100720165657Z<br>entryCSN: 20100720165657.625245Z#000000#000#000000<br>modifiersName: cn=config<br>modifyTimestamp: 20100720165657Z<br><br><br><b>olcDatabase={1}bdb.ldif:</b><br>
<br>dn: olcDatabase={1}bdb<br>objectClass: olcDatabaseConfig<br>objectClass: olcBdbConfig<br>olcDatabase: {1}bdb<br>olcDbDirectory: /var/lib/ldap<br>olcSuffix: dc=phoenix,dc=com<br>olcRootDN: cn=manager,dc=phoenix,dc=com<br>
olcRootPW:: c2VjcmV0<br>structuralObjectClass: olcBdbConfig<br>entryUUID: 8d37ea88-286b-102f-9995-8313efe688a2<br>creatorsName: cn=manager,cn=config<br>createTimestamp: 20100720165657Z<br>entryCSN: 20100720165733.125549Z#000000#00c#000000<br>
modifiersName: cn=manager,cn=config<br>modifyTimestamp: 20100720165733Z<br><br><br><b>olcDatabase={-1}frontend.ldif:</b><br><br>dn: olcDatabase={-1}frontend<br>objectClass: olcDatabaseConfig<br>objectClass: olcFrontendConfig<br>
olcDatabase: {-1}frontend<br>olcAddContentAcl: FALSE<br>olcLastMod: TRUE<br>olcMaxDerefDepth: 0<br>olcReadOnly: FALSE<br>olcSchemaDN: cn=Subschema<br>olcSyncUseSubentry: FALSE<br>olcMonitoring: FALSE<br>structuralObjectClass: olcDatabaseConfig<br>
entryUUID: 8d37c1a2-286b-102f-9994-8313efe688a2<br>creatorsName: cn=config<br>createTimestamp: 20100720165657Z<br>entryCSN: 20100720165657.625397Z#000000#000#000000<br>modifiersName: cn=config<br>modifyTimestamp: 20100720165657Z<br>
<br><br>the cn=schema directory has the following (I&#39;m not going to paste the contents of these files):<br><br>cn={0}core.ldif<br>cn={1}cosine.ldif<br>cn={2}inetorgperson.ldif<br>cn={3}nis.ldif<br><br><br>