Date: Thu, 7 Jun 2001 09:53:54 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Graham Barr <gbarr@pobox.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: read(2) and ETIMEDOUT Message-ID: <200106071653.f57Grsn73369@earth.backplane.com> References: <20010607171501.S50444@pobox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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?200106071653.f57Grsn73369>