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