Antw: Re: slapd-ldap and Multiple URIs: Dealing with hosts that are down

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

>>> Jesus Jr M Salvo <jesus.m.salvo@gmail.com> schrieb am 24.10.2013 um 10:59 in
Nachricht
<CALKjTzwLB6Eajd776sK1mqkAM=qOjrE5kW82bzqV-VVkMn5BZw@mail.gmail.com>:
> On 23 October 2013 19:10, Jesus Jr M Salvo <jesus.m.salvo@gmail.com> wrote:
>> On 23 October 2013 15:34, Philip Guenther
>> <guenther+ldaptech@sendmail.com> 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