lkml.org 
[lkml]   [1998]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Sendmail 8.9.0 claims a Linux kernel bug
Hello!

Late answer, but still...

In article <m0ypI9y-000aOnC@the-village.bc.nu> you write:
>> and every time the error happens, sendmail refuses connections for
>> 5 seconds.

>Fix sendmail, better yet get a better mail daemon

Better depends on your application.

>> What is going on here? This is a heavily loaded mail server. Is
>> this really a Linux kernel bug?

>No its a Linux following RFC1122 versus Sendmail following original BSD
>now POSIX 1003.1g draft somethinghuge. 2.1.x should be behaving as per
>POSIX draft. The 2.0 kernels follow the intent of the RFC - which I still
>maintain is technically superior. The fact you can see all those "no
>route to host" events tells you there are one way routing problems
>impacting mail. Followers of the Posix religion wouldnt have known.

>Posix is however now the official religion, rightly or wrongly so you have
>to run icmpinfo to see whats going on in the world. 2.1.x follows it.

RFC1122 did NOT specify that implementors have to change the workings
of accept(), but did only specify that there should be capabilities
to report those errors. It would have been better to include those
capabilities, but disabled by default, and you can enable them with
a setsockopt(). Dunno, perhaps that is the 2.1 way already...

>The 5 second delay in sendmail itself for this is just plain silly as
>well.

They are just as silly as any reaction to unexpected error codes.
What would you do with EINTR from accept(), while not having setup
signal handlers? What would you do with ENOENT, or EPERM? There is
no one true reaction for that, IMHO.

>Alan

Regards, Felix.

-
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.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.185 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site