"tcpflags 0x18<PUSH,ACK>; tcp_do_segment" kernel messages

Jordan Gordeev jgordeev at dir.bg
Thu Aug 23 03:40:20 PDT 2007


Stefan Lambrev wrote:
> Hello Eygene,
> 
> Eygene Ryabinkin wrote:
> 
>> Stefan, good day.
>>
>> Fri, Aug 17, 2007 at 11:04:20AM +0300, Stefan Lambrev wrote:
>>  
>>
>>> Their response is that the mail server timeout.
>>>     
>>
>>
>> And how they are detecting the timeout?  They are using alarm(),
>> just polling for the time with non-blocking read calls, setting the
>> socket timeout or something else?
>>   
> 
> They do not provide such information.
> But they have some kind of cronjob to restart the program if the PHP 
> script stall, which makes me think
> that it is not something very rare in this case.
> I'm still waiting better response from their support team and if this 
> happened will let you know.
Stefan, you can use ktrace to see what the program's doing and what it 
is getting from the kernel. I think the ktrace output + the tcpdump 
packet trace will be quite useful in tracking the problem down.
> 
>>  
>>
>>> Now the question is why the program things that the server timeouts 
>>> when it does not :)
>>>     
>>
>>
>> May be this is connected to the socket timeout stuff: chances are
>> good that the PHP program uses apr_socket_timeout_set(), so there
>> can be issues with SO_SNDTIMEO/SO_RCVTIMEO socket options in the
>> -CURRENT.  At least Apache (that I have problems with) sets keep-alived
>> sockets with apr_socket_timeout_set().  I will try to have a look
>> if this can be true.
>>
>> Thanks for your information!
>>
>> Mike, Robert, there are chances that some timeout code behaves
>> weirdly.  And maybe the magic number 3 (every 3rd keep-alived
>> connection seems to be dropped due to the timeout, Stefan sees it
>> too) should be searched in the timeout code.  Maybe you can give
>> some hints or point to the exact place where the error can occur?
>>
>> Thank you.
>>   
> 
> 



More information about the freebsd-current mailing list