Messages in this thread | | | Subject | Re: (Fwd) Re: 8.8.8: Useless error message about "getrequests" | Date | Fri, 30 Oct 1998 10:16:19 +0200 (EET) | From | Matti Aarnio <> |
| |
> Hello, > > it seems Linux 2.0.35 can return "no route to host" during an > accept() syscall, but not even syslog indicated which address was > involved. For debugging purposes it would be interesting to get that > information. I suspect someone behind a firewall is playing "routing > tricks".
Once upon a time I wrote accept() code according to BSD man-pages, and did way too abortative error handling if the error-code return was unexpected.
Then I installed that source to Solaris, and got LOTS of surprising error codes which (I think) did stem from the way how STREAMS works. That included things like "no route to host", ENOMEM, ENOSR...
For short: Linux has no more 'unexpected' behaviour regarding BSD documents than Solaris 2.5 has/had against its own documents. Sendmail needs to be fixed to tolerate it.
After all, in the systems there are some clearly FATAL error codes, and if those are gotten, then drastic meastures are called for. The 'unexpected' codes are treatable as if they were EINTR.
> Regards, > Ulrich
/Matti Aarnio <matti.aarnio@sonera.fi>
> ------- Forwarded Message Follows ------- > From: "Kari E. Hurtta" <Kari.Hurtta@ozone.fmi.fi> > Subject: Re: 8.8.8: Useless error message about "getrequests" > To: ulrich.windl@rz.uni-regensburg.de (Ulrich Windl) > Date sent: Fri, 30 Oct 1998 09:31:46 +0200 (EET) > Copies to: sendmail-bugs@sendmail.org > Send reply to: sendmail-bugs@sendmail.org (sendmail-bugs) > > Ulrich Windl: > > Hello I found an error message that is rather useless in 8.8.8: The > > information about which host or IP address is involved is missing. > > > > Oct 29 08:07:28 kgate sendmail[14080]: NOQUEUE: SYSERR(root): getrequests: accep > > t: No route to host > > Oct 29 08:08:01 kgate sendmail[14080]: NOQUEUE: SYSERR(root): getrequests: accep > > t: No route to host > > Oct 29 08:08:31 kgate sendmail[14080]: NOQUEUE: SYSERR(root): getrequests: accep > > t: No route to host > > If accept returns error, you don't have that information. Notice > that first point form where you can get that information, is > accept() system call: > > # #include <sys/types.h> > # #include <sys/socket.h> > # > # int accept (int s, struct sockaddr *addr, int *addrlen); > > > And that is impossible error on BSD networking. > > That is perhaps same kind than other impossible errors which > is seen on linux's accept(). Quote from KNOWNBUGS: > > | * accept() problem on Linux. > | > | Apparently, the accept() in sendmail daemon loop can return ETIMEDOUT > | and cause sendmail to sleep for 5 seconds during which time no new > | connections will be accepted. An error is reported to syslog: > | > | Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): > | getrequests: accept: Connection timed out > | > | "Connection timed out" is not documented as a valid return from > | accept(2) and this was believed to be a bug in the Linux kernel. > | Later information from the Linux kernel group states that Linux > | 2.0 kernels follow RFC1122 while sendmail follows the original BSD > | (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels > | will follow the POSIX draft. > > #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 or addrlen 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. > > > (And manual page on linuxes does not list other codes. Obviously > Linux documenttation is erronous.) > > / Kari Hurtta > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |