[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
LDAP API fails to honor timeouts (ITS#3322)
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