In article <m0xwZl0-0005FsC@lightning.swansea.linux.org.uk> you write:
>[...]
>> "Connection timed out" is not documented as a valid return from
>> accept(2) and this is believed to be a bug in the Linux kernel.
Right. That is not documented, not even on a Linux installation
(Debian 1.3).
>Its another good reason to run exim, qmail or zmailer ;). When we get a failed
>connection we report it back to user space (see RFC1122 hosts requirements
>which requires errors can get reported back). POSIX 1003.1g draft 6.4 (this
>is the first attempt at a socket API standard) contradicts RFC 1122. 2.0
>we follow the RFC. Given the POSIX standard is newer (but currently badly
>broken in numerous interesting ways) and most other hosts fail to follow
>RFC1122 on this issue 2.2 will probably give BSDlike results.
How about defaulting to the BSD behavior (not report errors on accept())
and allowing extended error reports to be enabled via setsockopt()?
>[...]
>Removing the rather bogus "randomly sleep 5 seconds" behaviour from sendmail
>is also sensible.
Sendmail uses BSD sockets. For the BSD socket interface, there are these
error codes defined for accept(2)
(from the OpenBSD manpage)
ERRORS
The accept() will fail if:
[EBADF] The descriptor is invalid.
[ENOTSOCK] The descriptor references a file, not a socket.
[EOPNOTSUPP] The referenced socket is not of type SOCK_STREAM.
[EFAULT] The addr parameter is not in a writable part of the user
address space.
[EWOULDBLOCK]
The socket is marked non-blocking and no connections are
present to be accepted.
[EMFILE] The per-process descriptor table is full.
[ENFILE] The system file table is full.
(from the Debian 1.3 manpage)
ERRORS
EBADF The descriptor is invalid.
ENOTSOCK
The descriptor references a file, not a socket.
EOPNOTSUPP
The referenced socket is not of type SOCK_STREAM.
EFAULT The addr parameter is not in a writable part of the
user address space.
EWOULDBLOCK
The socket is marked non-blocking and no connec
tions are present to be accepted.
So in neither of both the error code in question is documented.
Regards, Felix.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu