[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