[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl broke, connection loss
On Thu, 10 Dec 2009 09:36:33 +0100, Peter Mogensen <apm@mutex.dk> wrote:
> Quanah Gibson-Mount wrote:
>> --On Tuesday, December 08, 2009 5:40 PM +0100 Peter Mogensen
>> <apm@mutex.dk> wrote:
>>
>>> It was only when I also stopped server2, that server1 actually stopped.
>>
>> I would of course, at this point, expect an ITS has been filed, and a
>> fully detailed gdb backtrace submitted along with it.
>
> I'll try to reproduce something better to post in an ITS. As I said, it
> doens actually crash, it just hangs.
Remember you can use gdb to connect to a running process, using it's PID,
with a syntax like:
gdb /path/to/slapd PID
Then, something like "thread apply all bt".
> I can see with tcpdump, that server1 actually tries to connect once
> every minute to server2 and does establish an TLS connection, but after
> af few frames of application data it sends close notify.
> Another thing bothering me is that a few threads on server1 are using
> 99.9% CPU.
> (server2 is not accessed by clients, so it is mostly idle)
>
> Is it possible to temporarily turn of mirroring of cn=config, so I can
> raise loglevels on server2 without the change being replicated to
> server1 and thus hanging the whole system ?
Of course. However, according to your description of this problem, it seems
to be related to replication. So turning replication off will likely
interfere with your examination of the problem.
I recommend running slapd with the -d switch to see debug output (maybe
redirecting it to a file). Using the monitor overlay may also be useful, to
observe current connections on each server.
Hope this helps,
Jonathan