=C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason wrote:
On Mon, Feb 18, 2019 at 5:18 PM Howard Chu <hyc(a)symas.com>
> avarab(a)gmail.com wrote:
>> Full_Name: .var Arnfj.r. Bjarmason
>> Version: 2.4.44-21
>> OS: CentOS 7.6
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (220.127.116.11)
>> On a setup where you have a blackholed DNS server:
>> $ grep ^name /etc/resolv.conf
>> nameserver 18.104.22.168
>> Running e.g.:
>> $ time ldapsearch -l 2 -o nettimeout=3D1 [...]
>> Will (on my system) eventually return:
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>> real 0m24.039s
>> user 0m0.004s
>> sys 0m0.007s
>> It'll take around 48 seconds if I have two DNS servers. Running strac=
e(1) on it
>> reveals that it's sitting in a socket/connect/poll loop
trying to loo=
>> hostname of the LDAP server I'm trying to talk to.
>> Instead one of these options should limit time spent on DNS lookups, =
>> should be another option, so that you can run ldapsearch with
>> these options and be sure that it'll run in at most the
> The current code in libldap uses gethostbyname() and this API doesn't =
> any parameters for setting a timeout. You can configure a timeout
> system's /etc/resolv.conf or using RES_OPTIONS environment
> system's resolver(5) manpage.
> If you know of any widely available resolver API that allows specifyin=
> on individual queries, you're welcome to submit a patch
> The standard -lresolv doesn't provide such an interface.
That resolv.conf had "options timeout:2". That it didn't kick in is
probably a bug somewhere else, but it would still be handy if
ldapsearch had this itself, since the timeout you use for general
resolutions might not be what you want for ldapsearch.
If all you need is a timeout in the ldapsearch command, wrap it in a scri=
that sets the RES_OPTIONS environment variable.
So e.g. there could be a probe for getaddrinfo_a() on GNU systems.
> Closing this ITS.
Fair enough, but is that a "we don't want this ever" or "if someone
submitted a patch for (possibly OS-specific) DNS timeout we'd be
Generally not fond of features that aren't available cross-platform, part=
if that means it can only be tested on a particular OS. I guess for GNU e=
that are easily detected and widely supported it may be OK.
We already use getaddrinfo() if it's available, so adding getaddrinfo_a()=
not be too messy.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/