Hello tony,

I am sorry , I did not get your question .. because , db did not get corrupted for the case I explained, server got hungup

Thanks,

Arunachalam.

********************************************************************************************************

 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: openldap-software-bounces+arunachalamp=huawei.com@OpenLDAP.org [mailto:openldap-software-bounces+arunachalamp=huawei.com@OpenLDAP.org] On Behalf Of Tony Earnshaw
Sent: Monday, September 17, 2007 8:49 PM
Cc: openldap-software@openldap.org
Subject: Re: connection hangup -inference and solution?

Arunachalam Parthasarathy skrev, on 16-09-2007 10:35:

> I am using openldap 2.3.36 and bdb 4.5.20

Ok stuff. Updating OL will likely not help in this particular case.

> I am using delta syncrepl for synchronization and the configuration

> files are same as the examples provided in the test folder of package

> (for master and slave)

>

> I started the master and added some entries (I had already some 50,000

> entries)

>

> I started the slave and it was synchronizing.

>

> When I stopped the slave and client which was adding entries, in the

> master *I am getting connection hangup on a descriptor and the master is

> not responding to any client which are searching*

>

> *Can I know , why it is happening, and whats the way to get rid of this

> problem*

Been watching the thread for a couple or three of revs, but nowhere did

anyone match my experience with the same empirical experience.

In my case(s) it was caused by a corrupt (patched) 4.2.52 changelog DB.

Deleting the log after a stop slapd then restarting (so that the DB

automatically got rebuilt) fixed it. Runnings a (Buchan-adapted)

db_recover -c had had no effect at any stage.

Why the DB should have got corrupt in the first case, I can only

surmise. DB_CONFIG in that directory was reasonable, but consumers *did*

disappear for periods, due to system upgrade reboots before this occurred.

Systems were RHEL5 and FC6, OL versions were 2.3.37 and 2.3.38.

--Tonni

--

Tony Earnshaw

Email: tonni at hetnet dot nl