[Filterproxy-devel] Re: FilterProxy BUG

[Yann D. <yd...@fr...>]

Hi,

I'm looking at this problem while Guillaume is away.

On Tue, May 07, 2002 at 11:09:59AM -0500, Bob McElrath wrote:
> > >     2) $daemon->accept is returning false or undef (line 295).
> > >     IO::Socket (parent of HTTP::Daemon) is supposed to return undef upon
> > >     'failure'.  The only failure I can see is if the port it is binding
> > >     to is closed, or timeout, and clearly the latter is not happening.
> > >     Under some circumstances (timeout) IO::Socket::accept returns an
> > >     error code in $@.  Try printing out $@ in the "Exiting outside main
> > >     loop (BUG!)" message.
> > 
> > Yes, but accept(2) can't fail for other reasons that you should test
> > such as ECONNRESET. After the getpeername error, I get EPIPE, I tried to
> > launch accept again, it seems to trigger endless EPIPE errors.
> 
> This should not be possible.
> 
> The secondary connections (the HTTP::Daemon::ClientConn object returned
> by accept()) should be resettable.  But the listen socket should not be
> resettable.

A google search on "accept ECONNRESET" told me that BIND 9 had handled
a similar problem.  Comments from the source (BIND 9.2.1) says:

	 * Try to accept the new connection.  If the accept fails with
	 * EAGAIN or EINTR, simply poke the watcher to watch this socket
	 * again.  Also ignore ECONNRESET, which has been reported to
	 * be spuriously returned on Linux 2.2.19 although it is not
	 * a documented error for accept().

A quick search in linux-kernel and linux-net archives did no give
anything useful.


About errors to be "ignored", the accept(2) manpage says:

ERROR HANDLING
       Linux accept passes already-pending network errors on  the
       new  socket  as an error code from accept.  This behaviour
       differs from other BSD socket implementations.  For  reli­
       able  operation  the application should detect the network
       errors defined for the protocol  after  accept  and  treat
       them  like EAGAIN by retrying. In case of TCP/IP these are
       ENETDOWN, EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUN­
       REACH, EOPNOTSUPP, and ENETUNREACH.

I suppose that perl's accept() call takes care of this (or should) for
portability.

The EPIPE looks even more abnormal, and might be a result of perl's
accept() *not* handling this poorly-documented ECONNRESET case.  It's
probably useful to seek confirmation of this in perl lists.

-- 
Yann Dirson <Yan...@fr...>                 http://www.alcove.com/
Technical support manager                Responsable de l'assistance technique
Senior Free-Software Consultant          Consultant senior en Logiciels Libres
Debian developer (di...@de...)                        Développeur Debian