here is the back trace:
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
On Mon, May 11, 2009 at 6:20 PM, Anton Bobrov <[email protected]> wrote:
>
> 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 wrote:
>
>> One more thing, if I send a CONT signal to the OVD Process,
>> then the bind call returns & the search works as expected.
>>
>> On Mon, May 11, 2009 at 6:14 PM, denish patel <[email protected]
>> >wrote:
>>
>> Here is the netstat output:
>>> 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
>>>
>>>
>>> On Mon, May 11, 2009 at 6:09 PM, Anton Bobrov <[email protected]
>>> >wrote:
>>>
>>> do you use SSL/TLS on that connection? can you post netstat output
>>>> showing that client connection state when you observe blocked bind?
>>>>
>>>> denish patel wrote:
>>>>
>>>> Anton, Actually what I tried to mention was that
>>>>> 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.
>>>>>
>>>>> On Mon, May 11, 2009 at 5:59 PM, Anton Bobrov <[email protected]>
>>>>> wrote:
>>>>>
>>>>> 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().
>>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>> dev-tech-ldap mailing list
>>>>> [email protected]
>>>>> https://lists.mozilla.org/listinfo/dev-tech-ldap
>>>>>
>>>>>
>>
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap
