ldap_simple_bind blocks in Open Mode when the DS is in hang state
denish patel
I have a simple LDAP Client that uses the Mozilla LDAP SDK.
This client simulates how our software communicates with the Directory
Server (OVD / Sun DS).
Here are the steps that I follow:
1) ldap_init
2) ldap_set_option - set options -
a) Version
b) LDAP_X_OPT_CONNECT_TIMEOUT
c) LDAP_OPT_REFERRALS to LDAP_OPT_ON
d) LDAP_OPT_SIZELIMIT
e) LDAP_OPT_TIMELIMIT
f) LDAP_OPT_NETWORK_TIMEOUT (Unsuccessful even when the DS is up) (added
later)
g) PRLDAP_OPT_IO_MAX_TIMEOUT (Unsuccessful even when the DS is up)
(added later)
3) ldap_simple_bind
4) query the Directory Server (DS)
The client works perfectly when the DS is up.
However when the DS is given a STOP signal, the Client gets blocked on the
bind call.
I have tried setting the TCP Timeout to a low value, but even that did not
work.
Is there anything more that I need to do?
Thanks,
Denish
Anton Bobrov
what behavior do you expect in this case ? why do you think it
should timeout when you send SIGSTOP to the server process ?
denish patel
would not be responding,
the ldap_simple_bind() should return with a -1.
Thanks,
Denish
Anton Bobrov
you just pause server process execution with SIGSTOP but OS will keep
its files/sockets open and simply enqueue the data. connect and alike
will always succeed, recv and alike will block, on the client side so
none of the options you are setting will have any effect in this case.
the only thing you can do is to use async API and some timeout value
on LDAP protocol/operations level eg if you are not getting a response
to certain LDAP operation in 30 seconds bail out and return an error.
Anton Bobrov
denish, please keep this thread on the list. neither network or
connect timeout would apply in this case as i have explained in
my previous message. you can specify timeout for ldap_result()
call which is where it blocks in this case. again, this timeout
has nothing to do with network stack timeouts but simply a time
out for response on specific LDAP operation/s result/s.
denish patel wrote:
> Thank you for you quick response.
>
> But that is what I am doing. I am using ldap_simple_bind (which is async),
> & specifying the timeout value. (LDAP_OPT_NETWORK_TIMEOUT, _CONNECT_TIMEOUT)
> Is there anything else that I need to be using?
>
> Thanks,
> Denish
denish patel
I seem to get the point here.
Just to clarify, the LDAP Client is blocking on the ldap_simple_bind()
call & not the ldap_result() call.
Also when you say that:
---
the only thing you can do is to use async API and some timeout value
on LDAP protocol/operations level eg if you are not getting a response
to certain LDAP operation in 30 seconds bail out and return an error.
I tend to think that I am missing something here.
Wouldn't LDAP_OPT_TIMELIMIT, LDAP_X_OPT_CONNECT_TIMEOUT
be LDAP protocol level timeout values?
If the expected behaviour here is the same as you specified in your earlier
response, then the only solution I can think as of now is the use of alarm()
call / another thread monitoring the bind call.
Anton Bobrov
denish patel wrote:
> Apologies for that Anton.
> I seem to get the point here.
> Just to clarify, the LDAP Client is blocking on the ldap_simple_bind()
> call & not the ldap_result() call.
exactly the opposite.
> I tend to think that I am missing something here.
> Wouldn't LDAP_OPT_TIMELIMIT, LDAP_X_OPT_CONNECT_TIMEOUT
TIMELIMIT is timeout enforced by the server for search operations. it
has nothing to do with this. in any case it wont be applicable here
because your server is paused by SIGSTOP anyway. CONNECT_TIMEOUT will
never apply in this case because even with the server paused by STOP
client connect() call will succeed thus no connect timeout will occur.
> If the expected behaviour here is the same as you specified in your earlier
> response, then the only solution I can think as of now is the use of alarm()
> call / another thread monitoring the bind call.
all you have to do is to specify timeout argument for ldap_result().
denish patel
my LDAP Client blocks up on the ldap_simple_bind call.
So, when the DS has been stopped, I do not see the LDAP Client
coming out / moving ahead of the bind call.
So I do not even get to make the ldap_result call when the DS has been
stopped.
Anton Bobrov
do you use SSL/TLS on that connection? can you post netstat output
showing that client connection state when you observe blocked bind?
> _______________________________________________
> dev-tech-ldap mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-ldap
denish patel
I am not using TLS / SSL connection.
> netstat -apn | grep 1389
tcp 0 0 0.0.0.0:1389 0.0.0.0:*
LISTEN 17021/java
tcp 27 0 10.220.16.220:1389 10.220.16.220:36540
ESTABLISHED -
tcp 0 0 10.220.16.220:36540 10.220.16.220:1389
ESTABLISHED 20641/a.out
The output of the program is as follows:
Init'ing
Inited
Setting OptionsSetting LDAP_X_OPT_CONNECT_TIMEOUT
LDAP_X_OPT_CONNECT_TIMEOUT Set
Getting LDAP_X_OPT_CONNECT_TIMEOUT
Value of LDAP_X_OPT_CONNECT_TIMEOUT : 10000
Setting LDAP_OPT_REFERRALS
Setting LDAP_OPT_REFERRALS
LDAP_OPT_REFERRALS Done
Setting LDAP_OPT_SIZELIMIT
LDAP_OPT_SIZELIMIT Done
Setting LDAP_OPT_TIMELIMIT
LDAP_OPT_TIMELIMIT
Getting LDAP_OPT_TIMELIMIT
Value of LDAP_OPT_TIMELIMIT : 10
Setting LDAP_OPT_NETWORK_TIMEOUT
Error setting the Timeout option : Unknown errorLDAP_OPT_NETWORK_TIMEOUT Set
Getting LDAP_OPT_NETWORK_TIMEOUT
Error: ldap_get_option for NET_TIMEOUT: Unknown error
Value of LDAP_OPT_NETWORK_TIMEOUT : 0
Setting PRLDAP_OPT_IO_MAX_TIMEOUT
Error setting the PR timeout option : Unknown error
PRLDAP_OPT_IO_MAX_TIMEOUT Set
Setting LDAP_OPT_RECONNECT
LDAP_OPT_RECONNECT Set
Getting LDAP_OPT_RECONNECT
Value of LDAP_OPT_RECONNECT : 1
Getting PRLDAP_OPT_IO_MAX_TIMEOUT
Value of PRLDAP_OPT_IO_MAX_TIMEOUT : 0
Setting Protocol Version
Protocol Version Set
Binding to DS <- Blocked here.
Thanks,
Denish
denish patel
then the bind call returns & the search works as expected.
Anton Bobrov
that is to be expected. unless you somehow manage to overflow related
OS buffers by continuously sending data i expect you should be able
to resume it cleanly. can you post full backtrace on the client side
showing which call is blocking exactly ?
denish patel
write(1, "Setting PRLDAP_OPT_IO_MAX_TIMEOUT"..., 34Setting
PRLDAP_OPT_IO_MAX_TIMEOUT
) = 34
write(1, "Error setting the PR timeout opti"..., 52Error setting the PR
timeout option : Unknown error
) = 52
write(1, "PRLDAP_OPT_IO_MAX_TIMEOUT Set\n"..., 30PRLDAP_OPT_IO_MAX_TIMEOUT
Set
) = 30
write(1, "Setting LDAP_OPT_RECONNECT\n"..., 27Setting LDAP_OPT_RECONNECT
) = 27
write(1, "LDAP_OPT_RECONNECT Set\n"..., 23LDAP_OPT_RECONNECT Set
) = 23
write(1, "Getting LDAP_OPT_RECONNECT\n"..., 27Getting LDAP_OPT_RECONNECT
) = 27
write(1, "Value of LDAP_OPT_RECONNECT : 1\n"..., 32Value of
LDAP_OPT_RECONNECT : 1
) = 32
write(1, "Getting PRLDAP_OPT_IO_MAX_TIMEOUT"..., 34Getting
PRLDAP_OPT_IO_MAX_TIMEOUT
) = 34
write(1, "Value of PRLDAP_OPT_IO_MAX_TIMEOU"..., 39Value of
PRLDAP_OPT_IO_MAX_TIMEOUT : 0
) = 39
write(1, "Setting Protocol Version\n"..., 25Setting Protocol Version
) = 25
write(1, "Protocol Version Set\n"..., 21Protocol Version Set
) = 21
write(1, "Binding to DS\n"..., 14Binding to DS
) = 14
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1389),
sin_addr=inet_addr("10.220.16.220")}, 16) = -1 EINPROGRESS (Operation now in
progress)
poll([{fd=3, events=POLLOUT}], 1, 10000) = 1 ([{fd=3, revents=POLLOUT}])
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
time(NULL) = 1241901653
write(3, "0\31\2\1\1`\24\2\1\3\4\10cn=admin\200\5oblix"..., 27) = 27
poll([{fd=3, events=POLLIN}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}], 5, -1
Thanks,
Denish
Anton Bobrov
can you post a proper backtrace showing libldap calls as well ?
attach to your app with debugger of your choice and obtain full
backtrace on thread blocked in bind.
jenifer adam
> Apologies for that Anton.
> I seem to get the point here.
> Just to clarify, the LDAP Client is blocking on the ldap_simple_bind()
> call & not the ldap_result() call.
> Also when you say that:
> ---
> the only thing you can do is to use async API and some timeout value
> on LDAP protocol/operations level eg if you are not getting a response
> to certain LDAP operation in 30 seconds bail out and return an error.
> ---
>
> I tend to think that I am missing something here.
> Wouldn't LDAP_OPT_TIMELIMIT, LDAP_X_OPT_CONNECT_TIMEOUT
> be LDAP protocol level timeout values?
>
> If the expected behaviour here is the same as you specified in your earlier
> response, then the only solution I can think as of now is the use of alarm()
> call / another thread monitoring the bind call.
>
>
> > denish, please keep this thread on the list. neither network or
> > connect timeout would apply in this case as i have explained in
> > my previous message. you can specify timeout for ldap_result()
> > call which is where it blocks in this case. again, this timeout
> > has nothing to do with network stack timeouts but simply a time
> > out for response on specific LDAP operation/s result/s.
>
> > denish patel wrote:
>
> >> Thank you for you quick response.
>
> >> But that is what I am doing. I am using ldap_simple_bind (which is async),
> >> & specifying the timeout value. (LDAP_OPT_NETWORK_TIMEOUT,
> >> _CONNECT_TIMEOUT)
> >> Is there anything else that I need to be using?
>
> >> Thanks,
> >> Denish
>
> >> wrote:
>
> >> you just pause server process execution with SIGSTOP but OS will keep
> >>> its files/sockets open and simply enqueue the data. connect and alike
> >>> will always succeed, recv and alike will block, on the client side so
> >>> none of the options you are setting will have any effect in this case.
> >>> the only thing you can do is to use async API and some timeout value
> >>> on LDAP protocol/operations level eg if you are not getting a response
> >>> to certain LDAP operation in 30 seconds bail out and return an error.
>
> >>> denish patel wrote:
>
> >>> The behaviour I expect is that since the DS has been stopped & therefore
> >>>> would not be responding,
> >>>> the ldap_simple_bind() should return with a -1.
>
> >>>> Thanks,
> >>>> Denish
>