Re: [exim] Broken Pipe to Dovecot LMTP Socket

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Jeremy Harris
Fecha:  
A: exim-users
Asunto: Re: [exim] Broken Pipe to Dovecot LMTP Socket
On 26/10/16 12:53, Rical Jasan wrote:
> Is there anything I can throw into the signal handler to dig deeper, or
> do I need to look at either the system or Dovecot? It's strange that
> the "Broken pipe" occurs several times in succession, the message is
> ultimately delivered, but Exim still resends the message later.
>
> Is the transport legit?
>
> lmtp:
> driver = lmtp
> socket = /var/local/run/dovecot/lmtp
> batch_max = 32


Looks ok.

> 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 <= root@???
> U=root P=local S=366004 M8S=0 T="Logwatch for host.domain.tld (Linux)"
> from <root@???> 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? Memory overcommited?

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.
--
Cheers,
Jeremy