Re: [EXIM] accept() errors instead of accepting when network…

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Exim Users Mailing List
Fecha:  
A: exim-users
Asunto: Re: [EXIM] accept() errors instead of accepting when network unreachable
[ On Wed, November 18, 1998 at 12:18:53 (+0000), Malcolm Beattie wrote: ]
> Subject: Re: [EXIM] accept() errors instead of accepting when network unreachable
>
> I missed the original message but happened to spot this one. Getting
> additional "unexpected" error reports on accept() (and a few other
> networking syscalls) is something that tends to happen with Linux.
> The 2.0 kernel series are RFC1122 compliant whereas BSD-derived
> network stacks aren't. Under Linux 2.0, accept() can pass network
> error information up to user level. Software which doesn't expect
> this can get a bit confused: simply logging the error messages and
> treating the errors as EAGAIN (which is what I presume exim does) is
> reasonable behaviour. Now that the BSD-derived behaviour has been
> standardised in POSIX.1g and UNIX98, the Linux 2.1 kernels hide the
> addition information.


Just to "clarify" here a little. Yes, according to Alan Cox (one of the
Linux networking gurus), the Linux 2.0.x (and possibly 1.3.x and up)
kernel accept(2) routine might return any error code that recvmsg(2)
might return. I'm not sure what that really means but this is what
Weitse Venema and I have added to "our" respective mailers:

    errno != ECONNRESET && errno != ENETUNREACH && errno != EHOSTUNREACH
    && errno != ENOTCONN && errno != ENETDOWN && errno != EHOSTDOWN
    && errno != errno != ECONREFUSED


which are all ignored just as EINTR is on BSD systems. I currently wrap
the above portion of the expression in #ifdef LINUX, since so far as I
know there are still lots of STREAMS based TCP/IP stacks where
completely killing and restarting the daemon, or even rebooting
sometimes, is still required when accept(2) gets itself tied in a knot.

Alan has also admited to me that RFC1122 really doesn't come into the
picture here -- it has *nothing* to say about accept(2). W. Richard
Stevens' "TCP/IP Illustrated, Volume 2" seems concur in "Appendix C:
RFC1122 Compliance" as well as throughout where accept() is discussed.

-- 
                            Greg A. Woods


+1 416 218-0098      VE3TCP      <gwoods@???>      <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>


--
*** Exim information can be found at http://www.exim.org/ ***