segmentation fault when attempting to delete olcOverlay={0}syncprov entry in cn=config (Runtime) Configuration
I looked but couldn'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!
I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant output from "rpm -qa | grep ldap" on my server):
openldap2-client-2.4.21-51.1 openldap2-2.4.21-47.1 openldap2-back-meta-2.4.21-51.1
I'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 * segFaultOutput.bmp.*
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.
Here is the configuration from the ldif files in /etc/openldap/slapd.d
*cn=config.ldif:*
dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 8d35d270-286b-102f-998d-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165733.055688Z#000000#00c#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100720165733Z contextCSN: 20100720165732.317584Z#000000#000#000000 contextCSN: 20100720165733.125549Z#000000#00c#000000
*cn=schema.ldif*:
dn: cn=schema objectClass: olcSchemaConfig cn: schema structuralObjectClass: olcSchemaConfig entryUUID: 8d35e49a-286b-102f-998e-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.613177Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z
*olcDatabase={0}config.ldif*:
dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: 8d37bc20-286b-102f-9993-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.625245Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z
*olcDatabase={1}bdb.ldif:*
dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: 8d37ea88-286b-102f-9995-8313efe688a2 creatorsName: cn=manager,cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165733.125549Z#000000#00c#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100720165733Z
*olcDatabase={-1}frontend.ldif:*
dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 8d37c1a2-286b-102f-9994-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.625397Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z
the cn=schema directory has the following (I'm not going to paste the contents of these files):
cn={0}core.ldif cn={1}cosine.ldif cn={2}inetorgperson.ldif cn={3}nis.ldif
Am Dienstag 20 Juli 2010, 20:25:46 schrieb jon brandt:
I looked but couldn'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!
I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant output from "rpm -qa | grep ldap" on my server):
openldap2-client-2.4.21-51.1 openldap2-2.4.21-47.1 openldap2-back-meta-2.4.21-51.1
I'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 * segFaultOutput.bmp.*
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.
Hm, did you build your server with -DSLAP_CONFIG_DELETE? If yes, please note that delete support in cn=config is still experimental. So please test again with cvs HEAD if it works there. There have been some changes/fixes in that area recently.
If you didn't compile with -DSLAP_CONFIG_DELETE please make a bugreport slapd should have rejected the delete operation in that case.
Thanks for the reply Ralf!
I got the RPMs for SUSE I believe (i.e. I didn't build the server myself), so I'm assuming the DSLAP_CONFIG_DELETE flag was used. All the other deletes work fine (I'm adding then deleting other directives, for example olcMirrorMode or olcDbIndex and those delete just fine from cn=config). I will try to upgrade to a newer version and see if that helps. What is strange is that this fails on most of the servers I have setup, but there there is one server that has a bit more horsepower that doesn't have the issue, so this leads me to believe it is a timing related issue.
On Wed, Jul 21, 2010 at 9:18 AM, Ralf Haferkamp rhafer@suse.de wrote:
Am Dienstag 20 Juli 2010, 20:25:46 schrieb jon brandt:
I looked but couldn'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!
I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant output from "rpm -qa | grep ldap" on my server):
openldap2-client-2.4.21-51.1 openldap2-2.4.21-47.1 openldap2-back-meta-2.4.21-51.1
I'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 * segFaultOutput.bmp.*
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.
Hm, did you build your server with -DSLAP_CONFIG_DELETE? If yes, please note that delete support in cn=config is still experimental. So please test again with cvs HEAD if it works there. There have been some changes/fixes in that area recently.
If you didn't compile with -DSLAP_CONFIG_DELETE please make a bugreport slapd should have rejected the delete operation in that case.
-- Ralf
Am Mittwoch 21 Juli 2010, 18:26:58 schrieb jon brandt:
Thanks for the reply Ralf!
I got the RPMs for SUSE I believe (i.e. I didn't build the server myself), so I'm assuming the DSLAP_CONFIG_DELETE flag was used.
Yes, probably. Might I ask you to open a bug report at bugzilla.novell.com? So we can fix it and probably release an updated RPM.
All the other deletes work fine (I'm adding then deleting other directives, for example olcMirrorMode or olcDbIndex and those delete just fine from cn=config).
Yes. The problematic thing is deleting complete objects (e.g. overlays, databases). Deleting single Attributes should work just fine and doesn't require -DSLAP_CONFIG_DELETE.
I will try to upgrade to a newer version and see if that helps.
It'll probably just deny to execute the operations (e.g. when removing overlay entries from the frontend or config db). But I consider that better than crashing the server :).
regards, Ralf
What is strange is that this fails on most of the servers I have setup, but there there is one server that has a bit more horsepower that doesn't have the issue, so this leads me to believe it is a timing related issue.
On Wed, Jul 21, 2010 at 9:18 AM, Ralf Haferkamp rhafer@suse.de wrote:
Am Dienstag 20 Juli 2010, 20:25:46 schrieb jon brandt:
I looked but couldn'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!
I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant output from "rpm -qa | grep ldap" on my server):
openldap2-client-2.4.21-51.1 openldap2-2.4.21-47.1 openldap2-back-meta-2.4.21-51.1
I'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 * segFaultOutput.bmp.*
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.
Hm, did you build your server with -DSLAP_CONFIG_DELETE? If yes, please note that delete support in cn=config is still experimental. So please test again with cvs HEAD if it works there. There have been some changes/fixes in that area recently.
If you didn't compile with -DSLAP_CONFIG_DELETE please make a bugreport slapd should have rejected the delete operation in that case.
On 07/22/10 04:54 AM, Ralf Haferkamp wrote:
Am Mittwoch 21 Juli 2010, 18:26:58 schrieb jon brandt:
All the other deletes work fine (I'm adding then deleting other directives, for example olcMirrorMode or olcDbIndex and those delete just fine from cn=config).
Yes. The problematic thing is deleting complete objects (e.g. overlays, databases). Deleting single Attributes should work just fine and doesn't require -DSLAP_CONFIG_DELETE.
It the issue I had with adding an olcDbIndex to olcDatabase={1}hdb,cn=config a bug that should be reported?
(see thread "Able to delete olcDbIndex config attribute, but not add it.").
Ralf and everyone, I discovered that I had the DN of the syncprov overlay entry wrong. I had the following:
olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
I changed it to:
olcOverlay=syncprov,olcDatabase=*{1}bdb,*cn=config
And now the replication works between my two servers, AND when I do the remove tests, it doesn't crash the server ;o)
I can still open a bug report if you want, since having a bad config, then attempting to delete it probably shouldn't crash the server ;o).
Thanks again for everyone who helped.
J
On Wed, Jul 21, 2010 at 11:54 AM, Ralf Haferkamp rhafer@suse.de wrote:
Am Mittwoch 21 Juli 2010, 18:26:58 schrieb jon brandt:
Thanks for the reply Ralf!
I got the RPMs for SUSE I believe (i.e. I didn't build the server myself), so I'm assuming the DSLAP_CONFIG_DELETE flag was used.
Yes, probably. Might I ask you to open a bug report at bugzilla.novell.com? So we can fix it and probably release an updated RPM.
All the other deletes work fine (I'm adding then deleting other directives, for example olcMirrorMode or olcDbIndex and those delete just fine from cn=config).
Yes. The problematic thing is deleting complete objects (e.g. overlays, databases). Deleting single Attributes should work just fine and doesn't require -DSLAP_CONFIG_DELETE.
I will try to upgrade to a newer version and see if that helps.
It'll probably just deny to execute the operations (e.g. when removing overlay entries from the frontend or config db). But I consider that better than crashing the server :).
regards, Ralf
What is strange is that this fails on most of the servers I have setup, but there there is one server that has a bit more horsepower that doesn't have the issue, so this leads me to believe it is a timing related issue.
On Wed, Jul 21, 2010 at 9:18 AM, Ralf Haferkamp rhafer@suse.de wrote:
Am Dienstag 20 Juli 2010, 20:25:46 schrieb jon brandt:
I looked but couldn'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!
I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant output from "rpm -qa | grep ldap" on my server):
openldap2-client-2.4.21-51.1 openldap2-2.4.21-47.1 openldap2-back-meta-2.4.21-51.1
I'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 * segFaultOutput.bmp.*
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.
Hm, did you build your server with -DSLAP_CONFIG_DELETE? If yes, please note that delete support in cn=config is still experimental. So please test again with cvs HEAD if it works there. There have been some changes/fixes in that area recently.
If you didn't compile with -DSLAP_CONFIG_DELETE please make a bugreport slapd should have rejected the delete operation in that case.
openldap-technical@openldap.org
-
Ian Collins -
jon brandt -
Ralf Haferkamp