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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/