On 10/26/2016 05:57 AM, Jeremy Harris wrote: > On 26/10/16 12:53, Rical Jasan wrote: >> Here are the relevant (AFAICT) log lines (sorry if the line-wrapping is >> problematic; blank lines are in the log): >> >> 2016-10-26 00:00:14 [7838] cwd=/ 3 args: /usr/local/sbin/exim -t -i >> 2016-10-26 00:00:17 [7838] 1bzIC6-00022Q-7J <= [email protected] >> U=root P=local S=366004 M8S=0 T="Logwatch for host.domain.tld (Linux)" >> from <[email protected]> for root >> 2016-10-26 00:00:17 [8060] cwd=/var/local/spool/exim 3 args: >> /usr/local/sbin/exim -Mc 1bzIC6-00022Q-7J >> 2016-10-26 00:00:17 [8063] 1bzIC6-00022Q-7J Failed writing transport >> results to pipe: Broken pipe >> >> 2016-10-26 00:00:17 [8063] 1bzIC6-00022Q-7J Failed writing transport >> results to pipe: Broken pipe >> >> 2016-10-26 00:00:17 [8063] 1bzIC6-00022Q-7J Failed writing transport >> results to pipe: Broken pipe > > Ah, much more interesting. It's not Dovecot at all; this is an internal > pipe between Exim processes. A child process, having done talking > to Dovecot, is writing results back to its parent. This accounts for > the actual delivery working, by the way. The parent unexpectedly > dying is the problem...
> does something randomly go around your system killing processes? I hope not! > Memory overcommited? Hm, possibly. I don't have any messages about the oom killer reaping things, at least, but I see that I have been swapping. > It could be a bug causing that parent to dies on a segfault, but > pretty unlikely. You have to enable setuid-dumpable and fiddle > ulimit, to get a corefile (or not) to be certain. > > The triple-hit error is an artifact of the error-handling path; > really we only care about the first one. OK. The memory issue is easy enough to test/check, so I'll address that first and take it from there. Thank you for the help! Rical -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
