>>> Jesus Jr M Salvo <[email protected]> schrieb am 24.10.2013 um 10:59 in Nachricht <CALKjTzwLB6Eajd776sK1mqkAM=qojre5kw82bzqv-vvkmn5...@mail.gmail.com>: > On 23 October 2013 19:10, Jesus Jr M Salvo <[email protected]> wrote: >> On 23 October 2013 15:34, Philip Guenther >> <[email protected]> wrote: >>> On Wed, 23 Oct 2013, Jesus Jr M Salvo wrote: >>>> Using the meta backend, I have specified a list of LDAP URIs. >>>> >>>> I am testing what happens if the first URI becomes unresponsive ( e.g. >>>> The host was shutdown, etc. ). >>>> >>>> So I deliberately put in a bogus URI as the first URI that I know will >>>> not respond ( TCP SYN would be sent out by OpenLDAP, but no TCP ACK >>>> coming back ): >>> ... >>>> timeout 10 >>> ... >>>> With the above timeout setting, I was hoping that after 10 seconds, >>>> OpenLDAP will try the next URI it the first URI did not respond ... >>>> but it did not as per tshark capture below. >>>> >>>> What setting do I need to accomplish what I need ? >>> >>> man slapd-meta(5) >>> network-timeout <time> >>> Sets the network timeout value after which poll(2)/select(2) >>> following a connect(2) returns in case of no activity. The >>> value is in seconds, and it can be specified as for >>> idle-timeout. If set before any target specification, it > affects >>> all targets, unless overridden by any per-target directive. >>> >> >> I've tried that as well ... same thing. I was hoping that OpenLDAP >> will detect that no TCP SYN/ACK was received, so that it tries the >> next URI in the list. It does not even try the next URI in the list. > > I've removed all the timeout settings, and OpenLDAP does try the next > entry in the URI list when the first one does not respond. The default > seems to be 60 seconds before trying the next entry. > > However, I could not seem to modify this to a shorter period which is > what I was hoping to achieve.
I guess it's difficult for a TCP based protocol. If you are strictly on Intranet, you could try to fiddle with TCP timeouts to get a "connection timed out" earlier. However I guess if the destination port is just down, the error should be immediate already... Regards, Ulrich
