Bug 754474 - slapd process exits when put the database on read only mode while updates are coming to the server
Summary: slapd process exits when put the database on read only mode while updates are...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: 389
Classification: Retired
Component: Replication - General
Version: 1.2.0
Hardware: ia64
OS: Other
unspecified
urgent
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 389_1.2.10
TreeView+ depends on / blocked
 
Reported: 2011-11-16 15:59 UTC by Jyoti ranjan das
Modified: 2015-01-04 23:51 UTC (History)
2 users (show)

Fixed In Version: 389-ds-base-1.2.10.rc1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-07 16:11:12 UTC


Attachments (Terms of Use)

Description Jyoti ranjan das 2011-11-16 15:59:42 UTC
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:

Comment 1 Noriko Hosoi 2011-12-21 21:50:54 UTC
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.

Comment 2 Noriko Hosoi 2012-01-04 00:12:33 UTC
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.

Comment 3 Jyoti ranjan das 2012-01-04 06:28:26 UTC
(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

Comment 4 Martin Kosek 2012-01-04 13:13:13 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/13

Comment 5 Rich Megginson 2012-01-04 15:53:12 UTC
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.

Comment 6 Rich Megginson 2012-01-10 17:59:56 UTC
marking as screened because it has been cloned upstream

Comment 7 Rich Megginson 2012-02-07 16:11:12 UTC
Fixed in 389-ds-base-1.2.10.rc1 now in Fedora/EPEL Testing


Note You need to log in before you can comment on or make changes to this bug.