Bug 754474

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