Hello Simon
On 12/16/2014 05:38 PM, Simon Fraser wrote:
This is speculation, but what has happened to us in the past is that the LDAP server stopped responding to queries, but the TCP socket was still open for connections. A new TCP connection would be established, but the daemon would not be notified of it.
So, depending on precisely how the first LDAP server crashed, it may not be the same test as killing the process, but closer to sending it 'kill -STOP' (and then 'kill -CONT' afterwards, obviously)
Thank you very much for that hint. You were right. When i -SIGSTOP the slapd i receive a similar behaviour of dovecot as we had a few weeks ago.
So do you (or someone other) has a hint on how i could work around such a situation?
I found a statement from Timo Sirainen from June 2011:
http://www.dovecot.org/pipermail/dovecot/2011-June/059905.html
"...Fallbacking to another LDAP server is done by OpenLDAP internally..."
So i thought, there should be a possibility to "tweak" the ldap.conf.
I then found a german Post:
https://listen.jpberlin.de/pipermail/dovecot/2014-June/000506.html
Where someone mentioned some ldap.conf Settings:
BIND_POLICY soft TIMELIMIT 5 NETWORK_TIMEOUT 5 TIMEOUT 8
and a link to:
http://www.linuxquestions.org/questions/linux-enterprise-47/ldap-failover-ti...
which also uses these two settings:
BIND_TIMELIMIT 10 IDE_TIMELIMIT 10
I gave i try to them, but the result was still the same. Dovecot respectively OpenLDAP does not switch to another LDAP.
Best regards Matthias
Matthias Egger ETH Zurich Department of Information Technology maegger@ee.ethz.ch and Electrical Engineering IT Support Group (ISG.EE), ETL/F/24.1 Phone +41 (0)44 632 03 90 Physikstrasse 3, CH-8092 Zurich Fax +41 (0)44 632 11 95