--On Wednesday, April 02, 2008 9:26 PM -0400 Chris Adams
<[EMAIL PROTECTED]> wrote:
On Apr 2, 2008, at 8:19 PM, Quanah Gibson-Mount wrote:
And to be very clear, ldapsearch already sends its errors to stderr:
[EMAIL PROTECTED] ~]$ ldapsearch -x -h bogus -b "" 1>a 2>b
In the example I included, the server timeout error was sent to stderr if
the server was down (e.g. connect() gets an RST) but not in the case of a
timeout (the LDIF comment is all you get).
In this case, do you mean a timeout at the *protocol* level, where the
search hits a timelimit set on the server side?
While I'm on subject of ldap behavior, I noticed this because I've been
looking into the failure of the various APIs to either timeout or
implement server failover - e.g. ldapsearch -l1 -h dead_server will hang
indefinitely and, far more importantly, pam_ldap doesn't timeout and try
another server if its request isn't answered.
I found a couple of posts from you asking about the same kind of problems
in 2004 - did you ever find a clean solution for that? I just added some
code which sets SO_SNDTIMEO/SO_RCVTIMEO if ldo_tm_net isn't null (the
latter being set to the bind_timeout in pam_ldap) which partially fixes
the problem in that it no longer hangs until a dead server comes back up
but it simply returns a failure instead of attempting to connect to the
second LDAP server.
Do you use nscd?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
