On 2012-07-18 18:01, Gavin Henry wrote:
Hi Dave,
Have you been able to reproduce it since?
Thanks.
So far I've only had the one failure and I haven't been able to
reproduce it since.
That's tricky then. Did you file an ITS? Will check...
I haven't filed an ITS yet, but another
David Hawes wrote:
On 2012-07-18 18:01, Gavin Henry wrote:
Hi Dave,
Have you been able to reproduce it since?
Thanks.
So far I've only had the one failure and I haven't been able to
reproduce it since.
That's tricky then. Did you file an ITS? Will check...
I haven't filed an ITS
Clearly I need to upgrade and see if this still continues to happen.
Give back-mdb in 2.4.32 a try. It's completely deadlock free.
So usual rules apply right?
1. slapcat,
2. stop slapd
3. change backend definition
4. empty db dir or use a new one
5. slapadd
6. start slapd
or not stop/start
I think that even in the cn=config case, a stop/start is necessary,
because database can't be deleted, and I doubt a backend change can be
performed dynamically.
Maybe even some manual LDIF editing is necessary, something evil ;)
2012/8/15 Gavin Henry ghe...@suretec.co.uk:
Clearly I need to
Erwann Abalea wrote:
I think that even in the cn=config case, a stop/start is necessary,
because database can't be deleted, and I doubt a backend change can be
performed dynamically.
Maybe even some manual LDIF editing is necessary, something evil ;)
You can get the new database running,
I also have bt full output if needed.
Since restarting I have seen no issues with any of the instances and the
failed instance synced without issue.
Let me know if I should create an ITS.
Thanks,
Dave
Hi Dave,
Have you been able to reproduce it since?
Thanks.
--
Kind Regards,
Hi Dave,
Have you been able to reproduce it since?
Thanks.
So far I've only had the one failure and I haven't been able to
reproduce it since.
That's tricky then. Did you file an ITS? Will check...
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930
My environment consists of 1 provider and 6 consumer machines using
delta-syncrepl for replication. For some reason, one of the consumer
machines stopped receiving changes for several days and did not resume
syncing until a restart (SIGKILL).
All machines are running 2.4.30 with BerkeleyDB 4.7.25