Re: LDAP API fails to honor timeouts (ITS#3322)

[Kurt@OpenLDAP.org]

The timelimit you specified (via -l) is not a client
side API timeout.  The timelimit value is sent to
the server and indicates to the server that a
timeExceeded error should be returned if the operation
takes longer than the limit.  If this error occurs,
the API, as it would any other error, passes it to
the calling application.

The API does have a (limited) timeout capability, but
that's not be used here.

At 06:48 AM 9/7/2004, quanah@stanford.edu wrote:
>Full_Name: Quanah Gibson-Mount
>Version: 2.2.15
>OS: Solaris 8
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (171.66.182.82)
>
>
>This is somewhat related to ITS#2862, where I'm getting the same behavior from
>slurpd, but I'm adding in some interesting details from ldapsearch as well. 
>This also affected one of my Net::LDAP scripts.
>
>Actually, it doesn't just have to be the HD dying like I said in ITS#2862.  If
>slapd gets into a really weird state like I have on ldap4 (where slapd doesn't
>answer queries at all, but actually has an open socket:
>
>ldapsearch -d -1 -h ldap4
>
>ldap_create
>ldap_url_parse_ext(ldap://ldap4)
>ldap_pvt_sasl_getmech
>ldap_search
>put_filter: "(objectclass=*)"
>put_filter: simple
>put_simple_filter: "objectclass=*"
>ldap_send_initial_request
>ldap_new_connection
>ldap_int_open_connection
>ldap_connect_to_host: TCP ldap4:389
>ldap_new_socket: 4
>ldap_prepare_socket: 4
>ldap_connect_to_host: Trying 171.67.16.6:389
>ldap_connect_timeout: fd: 4 tm: -1 async: 0
>ldap_ndelay_on: 4
>
>slurpd will hang forever.  In fact, anything that uses the LDAP protocol will
>hang forever, and timeout values past to the client libraries will not be
>respected.  I'm not sure if this is a protocol issue, or a problem in the
>OpenLDAP API.  I would think that if no valid response is received from the
>socket, that after some point, the connection should timeout.  There does appear
>to be a timeout value that can be passed in, but it is not honored in this
>case:
>
>tribes:~> time ldapsearch -d -1 -l 15 -h ldap4.stanford.edu uid=quanah uid
>ldap_create
>ldap_url_parse_ext(ldap://ldap4.stanford.edu)
>ldap_pvt_sasl_getmech
>ldap_search
>put_filter: "(objectclass=*)"
>put_filter: simple
>put_simple_filter: "objectclass=*"
>ldap_send_initial_request
>ldap_new_connection
>ldap_int_open_connection
>ldap_connect_to_host: TCP ldap4.stanford.edu:389
>ldap_new_socket: 4
>ldap_prepare_socket: 4
>ldap_connect_to_host: Trying 171.67.16.6:389
>ldap_connect_timeout: fd: 4 tm: -1 async: 0
>ldap_ndelay_on: 4
>^C0.01u 0.02s 0:36.57 0.0%
>
>Here I specifically say use a 15 second timeout.  However after 36 seconds, the
>connection is still hanging.
>
>
>
>A backtrace of slurpd seems to show everything is essentially in a wait state:
>
>(gdb) thr apply all bt
>
>Thread 13 (Thread 14 (LWP 12)):
>#0  0xfef9f054 in _lwp_sema_wait () from /usr/lib/libc.so.1
>#1  0xfee68d0c in _co_timerset () from /usr/lib/libthread.so.1
>#2  0xfee7b730 in _thread_start () from /usr/lib/libthread.so.1
>#3  0xfee68c18 in _co_timerset () from /usr/lib/libthread.so.1
>
>Thread 12 (Thread 13        ):
>#0  0xfee6978c in _swtch () from /usr/lib/libthread.so.1
>#1  0xfee8ed74 in _srunnable () from /usr/lib/libthread.so.1
>#2  0x0013000c in ?? ()
>
>Thread 11 (Thread 12        ):
>#0  0xfee6978c in _swtch () from /usr/lib/libthread.so.1
>#1  0xfee8ed74 in _srunnable () from /usr/lib/libthread.so.1
>#2  0x0013000c in ?? ()
>
>Thread 10 (Thread 11        ):
>#0  0xfee6978c in _swtch () from /usr/lib/libthread.so.1
>#1  0xfee8ed74 in _srunnable () from /usr/lib/libthread.so.1
>#2  0x0013000c in ?? ()
>
>Thread 9 (Thread 10 (LWP 5)):
>#0  0xfef9d1e0 in _poll () from /usr/lib/libc.so.1
>#1  0xfef4d1a8 in select () from /usr/lib/libc.so.1
>#2  0xfee7b13c in select () from /usr/lib/libthread.so.1
>#3  0xff34da44 in ldap_result () from /usr/local/lib/libldap_r-2.2.so.7
>
>Thread 8 (Thread 3        ):
>#0  0xfef9f054 in _lwp_sema_wait () from /usr/lib/libc.so.1
>#1  0xfee69acc in _park () from /usr/lib/libthread.so.1
>#2  0xfee69794 in _swtch () from /usr/lib/libthread.so.1
>#3  0xfee6ddc4 in _reap_wait () from /usr/lib/libthread.so.1
>
>Thread 7 (Thread 1        ):
>#0  0xfef9f054 in _lwp_sema_wait () from /usr/lib/libc.so.1
>#1  0xfee69acc in _park () from /usr/lib/libthread.so.1
>#2  0xfee69794 in _swtch () from /usr/lib/libthread.so.1
>#3  0xfee6de1c in _reap_wait_cancel () from /usr/lib/libthread.so.1
>
>Thread 6 (LWP    5        ):
>#0  0xfef9d1e0 in _poll () from /usr/lib/libc.so.1
>#1  0xfef4d1a8 in select () from /usr/lib/libc.so.1
>#2  0xfee7b13c in select () from /usr/lib/libthread.so.1
>#3  0xff34da44 in ldap_result () from /usr/local/lib/libldap_r-2.2.so.7
>
>Thread 5 (LWP    10        ):
>#0  0xfef9f054 in _lwp_sema_wait () from /usr/lib/libc.so.1
>#1  0xfee69acc in _park () from /usr/lib/libthread.so.1
>#2  0xfee69794 in _swtch () from /usr/lib/libthread.so.1
>#3  0xfee6ddc4 in _reap_wait () from /usr/lib/libthread.so.1
>
>Thread 4 (LWP    12        ):
>#0  0xfef9f054 in _lwp_sema_wait () from /usr/lib/libc.so.1
>#1  0xfee68d0c in _co_timerset () from /usr/lib/libthread.so.1
>#2  0xfee7b730 in _thread_start () from /usr/lib/libthread.so.1
>#3  0xfee68c18 in _co_timerset () from /usr/lib/libthread.so.1
>
>Thread 3 (LWP    13        ):
>#0  0xfef9f054 in _lwp_sema_wait () from /usr/lib/libc.so.1
>#1  0xfee69acc in _park () from /usr/lib/libthread.so.1
>#2  0xfee69794 in _swtch () from /usr/lib/libthread.so.1
>#3  0xfee6de1c in _reap_wait_cancel () from /usr/lib/libthread.so.1
>
>Thread 2 (Thread 2 (LWP 2)):
>#0  0xfef9e9a4 in _signotifywait () from /usr/lib/libc.so.1
>#1  0xfee6ed5c in _dynamiclwps () from /usr/lib/libthread.so.1
>#2  0xfee72038 in thr_yield () from /usr/lib/libthread.so.1
>#3  0x00000008 in ?? ()
>
>Thread 1 (LWP    2        ):
>#0  0xfef9e9a4 in _signotifywait () from /usr/lib/libc.so.1
>#1  0xfee6ed5c in _dynamiclwps () from /usr/lib/libthread.so.1
>#2  0xfee72038 in thr_yield () from /usr/lib/libthread.so.1
>#3  0x00000008 in ?? ()
>#0  0xfef9e9a4 in _signotifywait () from /usr/lib/libc.so.1