On 09/04/2017 10:20 PM, Morgan Jones wrote:
> Hello Mark et al,
>
> This is a mea culpa—it turns out we’re running firewalld on our “new” centos 7 systems and it was blocking port 389. If I disable firewalld I can’t repeat the problem.
>
> Thanks for your help on this.
Thanks for the follow up, glad it got figured out.
Mark
>
> -morgan
>
>
>> On Aug 23, 2017, at 4:24 PM, Mark Reynolds <mareynol@xxxxxxxxxx> wrote:
>>
>>
>>
>> On 08/23/2017 03:09 PM, Morgan Jones wrote:
>>> Mark,
>>>
>>> See attached. The break in the log is where it hung and then came back to life.
>> Odd, I don't see the connection being closed. Looks like the client
>> (the console) did not send any requests during that time, what about the
>> other servers at that same time?
>>
>> 23/Aug/2017:12:56:13 <--> 23/Aug/2017:12:59:58
>>
>> Also, did you try registering the servers in a different order?
>>
>> Perhaps try and get a stack trace from the console during the hang using
>> jstack (from Oracle java)
>>
>> Thanks,
>> Mark
>>> I’m also going to follow up with our networking and security folks to see if we can find anything there. These hosts are all on the same subnet for what it’s worth.
>>>
>>> Thanks for the help.
>>>
>>> -morgan
>>>
>>>
>>>> On Aug 23, 2017, at 12:35 PM, Mark Reynolds <mareynol@xxxxxxxxxx> wrote:
>>>>
>>>>
>>>>
>>>> On 08/23/2017 12:31 PM, Morgan Jones wrote:
>>>>>> On Aug 23, 2017, at 12:17 PM, Mark Reynolds <mareynol@xxxxxxxxxx> wrote:
>>>>>>
>>>>>>
>>>>>>> [pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource temporarily unavailable)
>>>>>>> [pid 27442] recvmsg(14, 0x7f3880ef74d0, 0) = -1 EAGAIN (Resource temporarily unavailable)
>>>>>>> [pid 27442] poll([{fd=14, events=POLLRDNORM}, {fd=15, events=POLLRDNORM}], 2, 500 <unfinished ...>
>>>>>>> [pid 27440] <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
>>>>>>> [pid 27440] futex(0x7f38940cfd28, FUTEX_WAKE_PRIVATE, 1) = 0
>>>>>> Sorry forgot to comment on this...
>>>>>>
>>>>>> This explains the "hang" - connections to the remove server(s) are
>>>>>> timing out.
>>>>>>
>>>>>> Can you look at the DS access logs on a remote server during the hang
>>>>>> (note there is a 30 sec log buffer with the access log). Perhaps just
>>>>>> tail the access log, reproduce the hang (wait 30 seconds), and provide
>>>>>> the complete tail output.
>>>>> Aha, ok, thanks. Which access log do you want or do you want all of them?
>>>> Just the access log from the server that triggers the initial hang.
>>>>> -morgan
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
