Date: Thu, 23 Aug 2007 13:41:03 +0300 From: Jordan Gordeev <jgordeev@dir.bg> To: Stefan Lambrev <stefan.lambrev@moneybookers.com> Cc: current@freebsd.org Subject: Re: "tcpflags 0x18<PUSH,ACK>; tcp_do_segment" kernel messages Message-ID: <46CD643F.9040003@dir.bg> In-Reply-To: <46C97E13.3080002@moneybookers.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46CD643F.9040003>