On Mon, 3 Dec 2001, Chris wrote:
> Apologies for the HTML crap in that last one. Found cores on a few more
> machines, same spot. These machines are all OSF1/Digital Unix, V4.0 -- I'm
> not sure if there's something different about their resolver libraries (if
> that's what's messing things up here).
The problem is happening when Exim passes a TCP/IP connection to a new
delivery process, to deliver another message down the same channel. It
appears that the function getpeername(), which is called to determine the
IP address of the open connection, is failing, leaving the address
unset. This leads to the crash.
There is a bug in Exim in that it is not checking whether getpeername()
is working or not. The patch below installs such a check. It will cause
output to your main and panic logs when getpeername() fails. It then
sets the IP address to an empty string, which will cause the delivery
not to happen. The message will get delivered later by some other
process.
I wonder if this is a problem with the OS?
Let me know what happens with this patch.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
*** exim-3.33/src/transports/smtp.c Wed Aug 15 12:09:13 2001
--- transports/smtp.c Tue Dec 4 11:50:17 2001
***************
*** 1812,1817 ****
--- 1812,1824 ----
continue_host_address = host_ntoa(-1, (struct sockaddr *)(&continue_sock),
NULL, NULL);
+ if (continue_host_address == NULL)
+ {
+ log_write(0, LOG_MAIN|LOG_PANIC, "failed to get IP address of stdin "
+ "when socket passed from previous delivery: %s", strerror(errno));
+ continue_host_address = "";
+ }
+
DEBUG(9) debug_printf("already connected to %s [%s]\n", continue_hostname,
continue_host_address);
}
