On Wed, Mar 22, 2006 at 09:37:24AM +0000, Philip Hazel wrote:
> On Tue, 21 Mar 2006, Chris Lightfoot wrote:
>
> > Further inspection with ktrace indicates that something
> > was setting O_NONBLOCK on the input stream (smtp_in in
> > smtp_in.c); the first read from the stream will then
> > typically fail with -EAGAIN, which is treated as an error.
>
> As you say, Exim doesn't use O_NONBLOCK on the input file descriptor,
> and this problem has not been reported by anybody else. There are
> certainly people running Exim under FreeBSD - indeed I tested it on the
> exim.org machine.
a similar problem has been, though -- I was thinking about
this one:
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20041101/msg00004.html
> > So, anyway, I have a temporary fix, but if it'd be useful
> > to investigate this further I'm happy to help.
>
> I don't think there's anything I can do myself, because the problem
> doesn't arise on the FreeBSD system to which I have access. Your fix
> seems innocuous, but I'm not too keen on just putting it in without
> understanding why it should be necessary.
I believe it's because exim links against libc_r (because
it is linked against libcrypto, which itself is linked
against libc_r). In this version of FreeBSD
(5.2.1-RELEASE) the threads library is a userspace one,
and I think it must be setting O_NONBLOCK on stdin for
some reason of its own. However, I haven't been able to
localise this completely (gdb doesn't seem to enjoy
debugging the startup code very much).
My patch isn't harmless, sadly -- it results in a file
descriptor leak which I also haven't been able to
localise. However, rebuilding the port with
WITHOUT_TLS=yes fixes the problem, which is enough for me.
--
Chris Lightfoot
mySociety
