From owner-freebsd-current@FreeBSD.ORG Thu Aug 23 10:40:19 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F030316A419 for ; Thu, 23 Aug 2007 10:40:19 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from dir.bg (mail.dir.bg [194.145.63.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4737213C45B for ; Thu, 23 Aug 2007 10:40:18 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from [87.126.192.227] (account jgordeev HELO [10.102.9.50]) by dir.bg (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 29888919; Thu, 23 Aug 2007 13:40:16 +0300 Message-ID: <46CD643F.9040003@dir.bg> Date: Thu, 23 Aug 2007 13:41:03 +0300 From: Jordan Gordeev User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20070606 X-Accept-Language: bg, en MIME-Version: 1.0 To: Stefan Lambrev References: <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> <46C30FA6.7060108@moneybookers.com> <20070815145640.GQ988@void.codelabs.ru> <46C319DD.3010806@moneybookers.com> <20070815172731.GR988@void.codelabs.ru> <46C3FEBC.80409@moneybookers.com> <20070816080516.GW988@void.codelabs.ru> <46C55684.4050402@moneybookers.com> <20070817083135.GM988@void.codelabs.ru> <46C97E13.3080002@moneybookers.com> In-Reply-To: <46C97E13.3080002@moneybookers.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2007 10:40:20 -0000 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. >> > >