Hide Forgot
Description of problem: slapd process exits when put the database on read only mode while updates are coming to the server. Version-Release number of selected component (if applicable): 389 1.2.0 How reproducible: Sometime Steps to Reproduce: 1. Put the database on readonly mode while the updates are coming to the server. 2. 3. Actual results: "ns-salpd" process exits. Expected results: Additional info:
Could you give us more detailed steps? While I was adding entries to the database, I changed the db's readonly value to on: $ ldapmodify [...] dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-readonly nsslapd-readonly: on modifying entry cn=userRoot,cn=ldbm database,cn=plugins,cn=config Then, the add stopped with the error code 53 as expected. [..] adding new entry uid=FPiercey158, ou=Product Testing, dc=example,dc=com adding new entry uid=LElgar159, ou=Payroll, dc=example,dc=com ldap_add: DSA is unwilling to perform ldap_add: additional info: database is read-only $ echo $? 53 The ns-slapd is up and running.
Thanks for providing us the information. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Yes, we rebuilt it with --enable--debug. Below is the error message what it writes to the error log before PA_ASSERT(0) ================== [16/Nov/2011:13:06:02 +051800] NSMMReplicationPlugin - replica_write_ruv: failed to update RUV tombstone for dc=ind,dc=hp,dc=com; LDAP error – 53 ==================== Considering the fact that we rebuilt with --enable-debug, what do you suggest how can we handle this situation?. Will it be any problem if we continue in this scenario without PA_ASSERT? I tested this scenario by removing PA_ASSERT from the code, I didn't hit any issue. But this function doesn't have any return value, so we never know where it will create any problem. Regards, Jyoti ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The issue is that a modify and the followed state update (replica_write_ruv) should be in one transaction, but it is currently not. This should be addressed again when the functionality is fully implemented.
(In reply to comment #2) > Thanks for providing us the information. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Yes, we rebuilt it with --enable--debug. Below is the error message what it > writes to the error log before PA_ASSERT(0) > > ================== > [16/Nov/2011:13:06:02 +051800] NSMMReplicationPlugin - replica_write_ruv: > failed to update RUV tombstone for dc=ind,dc=hp,dc=com; LDAP error – 53 > ==================== > > Considering the fact that we rebuilt with --enable-debug, what do you suggest > how can we handle this situation?. > > Will it be any problem if we continue in this scenario without PA_ASSERT? > > I tested this scenario by removing PA_ASSERT from the code, I didn't hit any > issue. But this function doesn't have any return value, so we never know > where it will create any problem. > > Regards, > Jyoti > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > The issue is that a modify and the followed state update (replica_write_ruv) > should be in one transaction, but it is currently not. This should be > addressed again when the functionality is fully implemented. Thanks for this information!!! Do you have any idea when the fully implemented functionality will be made available? Also, do you think we can handle this issue with the fix what i have mentioned above? Regards, Jyoti Regards, Jyoti
Upstream ticket: https://fedorahosted.org/389/ticket/13
The problem is that in this case replica_write_ruv() is called from the eq_loop, which means there is no transaction. I think the proper solution is to just log a message at the REPL log level stating that the ruv update could not be completed because the database is in read-only mode. This is fine and should not cause any harm.
marking as screened because it has been cloned upstream
Fixed in 389-ds-base-1.2.10.rc1 now in Fedora/EPEL Testing