On 11/15/2011 09:34 PM, Das, Jyoti Ranjan (STSD) wrote:
> Hi Rich,
>
> Thanks a lot for your reply.
>
> Does it produce a core dump, or just exit?
> It's only just exit. There is a force exit (  PR_ASSERT (0);) after putting 
> the below error meaasge
>
> File: /ldapserver/ldap/servers/plugins/replication/repl5_replica.c
> else /* error */
>           {                 char ebuf[BUFSIZ];
>                        slapi_log_error(SLAPI_LOG_FATAL, repl_plugin_name,
>                            "replica_write_ruv: failed to update RUV tombstone 
> for %s; "
>                           "LDAP error - %d\n",
>                          escape_string(slapi_sdn_get_dn(r->repl_root),ebuf), 
> rc);
>                   PR_ASSERT (0);
>           }
> Why are you trying to put the db into read-only mode?
> To make sure no more changes can reach to the database. But this I am doing 
> while changes are coming in.
>
> What platform? What version of 389-ds-base?
> It's HP-UX.  1.2.1 Version of 389-ds-base.
Please file a bug - there should not be a PR_ASSERT there.
> Regards,
> Jyoti
>
>
>
> -----Original Message-----
> From: Rich Megginson [mailto:rmegg...@redhat.com]
> Sent: Tuesday, November 15, 2011 8:35 PM
> To: 389-us...@lists.fedoraproject.org
> Cc: Das, Jyoti Ranjan (STSD)
> Subject: Re: slapd crashes when put the database on read only mode while 
> updates are coming to the server
>
>> Hi,
>>
>> When I put the database on read only mode(nsslapd-readonly : on) while
>> changes are coming to the server, "ns-slapd" process abort
>>
> Does it produce a core dump, or just exit?
> Why are you trying to put the db into read-only mode?
> What platform? What version of 389-ds-base?
>> abnormally with the following error message.
>>
>> "NSMMReplicationPlugin - replica_write_ruv: failed to update RUV
>> tombstone for o=SWIFT; LDAP error - 53"
>>
> This seems correct - if the database is in read-only mode, it cannot process 
> the update operation, which includes writing the replication state 
> information (the RUV tombstone). But it shouldn't exit and it definitely 
> should not core dump.
>> Below is the one pattern which is from error log where I see this
>> occurring.
>>
>> ======================================
>>
>> [15/Nov/2011:11:57:59 +051800] - do_modify: dn (cn=userRoot,cn=ldbm
>> database,cn=plugins,cn=config)
>>
>> [15/Nov/2011:11:57:59 +051800] - modifications:
>>
>> [15/Nov/2011:11:57:59 +051800] - replace: nsslapd-readonly
>>
>> [15/Nov/2011:11:57:59 +051800] - mtn_lock : lock count : 1
>>
>> [15/Nov/2011:11:57:59 +051800] - mapping tree selected backend :
>> frontend-internal
>>
>> [15/Nov/2011:11:57:59 +051800] - mtn_unlock : lock count : 0
>>
>> [15/Nov/2011:11:57:59 +051800] - mtn_lock : lock count : 1
>>
>> [15/Nov/2011:11:57:59 +051800] - mapping tree selected backend :
>> frontend-internal
>>
>> [15/Nov/2011:11:57:59 +051800] - mtn_unlock : lock count : 0
>>
>> [15/Nov/2011:11:57:59 +051800] - mapping tree release backend :
>> frontend-internal
>>
>> [15/Nov/2011:11:57:59 +051800] - nsslapd-readonly: on
>>
>> [15/Nov/2011:11:57:59 +051800] - replace: nsslapd-readonly
>>
>> [15/Nov/2011:11:57:59 +051800] - -
>>
>> [15/Nov/2011:11:57:59 +051800] - modifiersname: cn=directory manager
>>
>> [15/Nov/2011:11:57:59 +051800] - replace: modifiersname
>>
>> [15/Nov/2011:11:57:59 +051800] - -
>>
>> [15/Nov/2011:11:57:59 +051800] - modifytimestamp: 20111115062759Z
>>
>> [15/Nov/2011:11:57:59 +051800] - replace: modifytimestamp
>>
>> [15/Nov/2011:11:57:59 +051800] - -
>>
>> [15/Nov/2011:11:57:59 +051800] - mtn_lock : lock count : 1
>>
>> [15/Nov/2011:11:57:59 +051800] - mapping tree selected backend :
>> frontend-internal
>>
>> [15/Nov/2011:11:57:59 +051800] - mtn_unlock : lock count : 0
>>
>> [15/Nov/2011:11:57:59 +051800] - nsState:
>>
>> [15/Nov/2011:11:58:00 +051800] - replace: nsState
>>
>> [15/Nov/2011:11:58:00 +051800] - -
>>
>> [15/Nov/2011:11:58:00 +051800] - modifiersname: cn=Multimaster
>> Replication Plugin,cn=plugins,cn=config
>>
>> [15/Nov/2011:11:58:00 +051800] - replace: modifiersname
>>
>> [15/Nov/2011:11:58:00 +051800] - -
>>
>> [15/Nov/2011:11:58:00 +051800] - modifytimestamp: 20111115062759Z
>>
>> [15/Nov/2011:11:58:00 +051800] - replace: modifytimestamp
>>
>> [15/Nov/2011:11:58:00 +051800] - -
>>
>> [15/Nov/2011:11:58:00 +051800] - mtn_lock : lock count : 1
>>
>> [15/Nov/2011:11:58:00 +051800] - mapping tree selected backend :
>> userRoot
>>
>> [15/Nov/2011:11:58:00 +051800] - mtn_unlock : lock count : 0
>>
>> [15/Nov/2011:11:58:00 +051800] NSMMReplicationPlugin -
>> replica_write_ruv: failed to update RUV tombstone for dc=ind, dc=hp,
>> dc=com; LDAP error - 53
>>
>> ====================
>>
>> While database put on the read only mode and the same time replica
>> state is getting updated which is in-tern try to update the replica
>> RUV, it gets into this issue.
>>
>> Anybody has any thought into this issue why it's happening?
>>
> The code doesn't expect the database to be in read-only mode while it is 
> receiving updates?
>> When the "nsState" do gets updated for the replica?
>>
> When it needs to be.
>> Regards,
>>
>> Jyoti
>>

--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Reply via email to