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-timeout-client-setting-847718/ 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 maeg...@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
smime.p7s
Description: S/MIME Cryptographic Signature
