Re: More on FIN_WAIT_2

[Randy Terbush <ra...@zyzzyva.com>]

> Randy Terbush liltingly intones:
> > 
> > I took a closer look at lingering_close().
> > 
> > While I am not being plagued by these problems on FreeBSD,
> > I am seeing errors logged that indicate read failures in
> > lingering_close().
> > 
> > Seems that it would be helpful to check the return of the
> > half close. I also raise the question, should we be flushing
> > this before the half close? 
> > 
> The close() should itself do a flush, no? Oh, unless you mean a bflush().

Actually looking at this closer, we do call bflush() before calling
lingering_close().

> > The other comments that Chuck made about Nagle not working is
> > kind of interesting. I'm wondering if it would not be worth
> > changing make_sock() so that we could log a failure of sock_disable_nagle()
> > to a logfile instead of stderr. I'm suspicious that there might be
> > some connection here...
> > 
> I think I was mentioning sock_disable_nagle() failures in the context of
> the reported proxy weirdness, where children would remain tied up, in
> write mode, but the connection would be completed. No one's said anything
> lately about that, and I've been unable to get it to happen on the OS I
> have access to at work (FreeBSD, BSDI, SPARC Solaris 2.5, and IRIX 5.3).
> That means there could be a race condition there, or something else weird
> happening, possibly on an alarm timeout.

That's the other thing I see. Perhaps we need to be calling alarm(0)
in lingering_close()?