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