From owner-freebsd-hackers Sun Jun 10 5:59:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by hub.freebsd.org (Postfix) with ESMTP id 863DF37B401 for ; Sun, 10 Jun 2001 05:59:31 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id PWT09150; Sun, 10 Jun 2001 15:59:06 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.11.3/8.11.3) id f5ACv9q01705; Sun, 10 Jun 2001 15:57:09 +0300 (EEST) (envelope-from netch) Date: Sun, 10 Jun 2001 15:57:09 +0300 From: Valentin Nechayev To: Graham Barr Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: read(2) and ETIMEDOUT Message-ID: <20010610155709.A1179@iv.nn.kiev.ua> References: <20010607171501.S50444@pobox.com> <20010607150917.U1832@superconductor.rush.net> <20010607201846.E50444@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010607201846.E50444@pobox.com>; from gbarr@pobox.com on Thu, Jun 07, 2001 at 08:18:46PM +0100 X-42: On Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thu, Jun 07, 2001 at 20:18:46, gbarr (Graham Barr) wrote about "Re: read(2) and ETIMEDOUT": > > I'm quite sure ETIMEDOUT is a result of hitting the setsockopt > > SO_RCVTIMEO value when doing a read. > I had been thinking along those lines too. But immediately before calling > read, select said there was data to read, So it should not block, but > read what data is there and return. This is ideological error from you: select does _not_ say "there is data to read", it only says "read() will not block". EOF (when read() returns 0) and any situation where read() returns -1-and-errno also are such. But, this error does not (I think) influe to produce ETIMEDOUTs. > Also why does this happen only every few hours ? There is a lot of > data going through these connections maybe the timer for SO_RCVTIMEO > is not being reset. You should determine exact cases where ETIMEDOUT occurs. netch@iv:/usr/REL4/src/sys/netinet>fgrep ETIMEDOUT *.c tcp_input.c: tcp_drop(sototcpcb(so2), ETIMEDOUT); tcp_subr.c: if (errno == ETIMEDOUT && tp->t_softerror) tcp_timer.c: tp = tcp_drop(tp, ETIMEDOUT); tcp_timer.c: tp = tcp_drop(tp, ETIMEDOUT); tcp_timer.c: tp->t_softerror : ETIMEDOUT); Add debug printf()s with __LINE__, __FILE__, variables used by stack to make solution to drop connection. Collect statistics. /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message