Date: Thu, 7 Jun 2001 18:00:11 +0100 From: Graham Barr <gbarr@pobox.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: read(2) and ETIMEDOUT Message-ID: <20010607180011.U50444@pobox.com> In-Reply-To: <200106071653.f57Grsn73369@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Jun 07, 2001 at 09:53:54AM -0700 References: <20010607171501.S50444@pobox.com> <200106071653.f57Grsn73369@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks, I will try setting errno, but I don't think it is signals. I have been running truss on the process. The relevant part is gettimeofday(0xbfbffa54,0x0) = 0 (0x0) select(0x50,0x93f8c90,0x0,0x0,0xbfbffa74) = 3 (0x3) read(0x16,0xa2da000,0x8000) ERR#60 'Operation timed out' In fact there are no signals in the whole truss output Graham. On Thu, Jun 07, 2001 at 09:53:54AM -0700, Matt Dillon wrote: > :A while ago our systems were upgraded from 4.2 to 4.3-RC, and at > :this time we started seeing problems that I am having a difficult > :time tracking down. > : > :We have a server process which is connected to by many other > :machines, each of them streams data in via tcp/ip. These connections > :are pretty much permanent. > : > :All had been running fine for a long time before the upgrade, but > :now we have a problem with read(2) returning an error ETIMEDOUT, > :which causes our code to close the connection. > : > :The strange thing is that things are fine for a few hours, then > :all of a sudden we see each of the connections fail with this error. > :Then after the clients have reconnected, all is fine for a few > :hours and then they all do it again. > : > :The problem I am having in tracking this down is that man 2 read > :does not specify ETIMEDOUT as an error that can be returned from > :read(2) and man errno specifies that it would be returned from > :connect(2) or send(2) > : > :So, here is my question. Does anyone know under what circumstance > :ETIMEDOUT may be returned from read(2) or is this a potential bug > :somewhere ? > : > :Thanks, > :Graham. > > This seems very odd. I recommend setting errno to 0 prior to calling > read() to make sure that it is actually read() that is setting the > errno. You should also sift through your code and look closely at any > signal handlers you might have - system calls made from inside a signal > handler can rip errno right out from under the code the signal > interrupted. > > -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010607180011.U50444>