Re: Strange messages with 1.61

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Christoph Lameter
Fecha:  
A: Philip Hazel
Cc: exim-users
Asunto: Re: Strange messages with 1.61
> > The following address(es) have yet to be delivered:
> > Bretter@???: smtp transport process returned a non-zero
> > status (0x000b)
> > JPHAHN@???: smtp transport process returned a non-zero
> > status (0x000b)
> > drkjster@???: smtp transport process returned a non-zero
> > status (0x000b)
> > no0ne@???: smtp transport process returned a non-zero status
> > (0x000b)
>
> You are getting the message because you have set freeze_tell_mailmaster
> in your configuration. Since it is complaining about a subprocess, I
> deduce you have also set remote_max_parallel to some number greater than
> one.

I have removed that option and set
auto_thaw = 1h

Messages will be sent on retries without a problem. But there is a serious
problem in exim under load under Linux. This never happens on systems
running with just a few thousand messages a day.

>
> The message means that when Exim ran a sub-process to deliver to that
> address, the subprocess terminated with status 0x000b. This is bad and
> indicates that the process died on signal 11, which on Linux is SIGSEGV
> (at least on the version I looked at).



>
> In other words, Exim is crashing for some reason. Does it do that
> repeatedly on those addresses? Is it always the same addresses? Are
> there any core files? Various bugs were fixed in 1.62, but nothing that
> seems to relate to this.


The addresses are rather random. No core files were produced and no
messages in the system logs are indicating anything wrong or an abnormal
termination of a program. Delivery works when the message delivery is
retried.

> If it is repeatable, try forcing a delivery with debugging turned on,
>
> exim -d9 -M <messag-id>
>
> and send me (not the list!) the output. It might give some clue as to
> what the problem is.


Trouble is that the system delivers over 60.000 messages a day. I have no
idea how to produce meaningful debugging output.

The Cyrix-166 produces the above problem frequently. It only occasionally
happens on the slower 486DX66.

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
Please always CC me when replying to posts on mailing lists.