we are having 100+ rules like these in the central_filter
if $message_body: contains "blah blah"
logfile /var/log/refuse.log
logwrite "A1A32 $tod_log $original_domain $message_id
$sender_address"
fail text "Mail has not been delivered as it is marked as
spam. Check content and resend"
seen finish
endif
if $message_body: contains "another blah blah check"
logfile /var/log/refuse.log
logwrite "A1A33 $tod_log $original_domain $message_id
$sender_address"
fail text "Mail has not been delivered as it is marked as
spam. Check content and resend"
seen finish
endif
in the central_filter, removing those delivers the message correctly,
appears that there is an array that is not emptied after each
message_body compare and therefore goobles up memory and fails when
reaching 2gb?
On 23/05/2022 16:42, Jeremy Harris via Exim-users wrote: > On 23/05/2022 16:04, Laura Williamson via Exim-users wrote:
>> Have another one (in queue, undelivered) that I can test with.
>
> # exim -d+all -M <message-id> 2>&1 | tee my_debug_log_file
>
> should get us debug for an attempt to deliver a message
> that is queued. With luck that will help locate where
> it's doing this odd memory-allocation. The important bit
> will be that leading up to the log line being generated
> (I assuming this is the same problem, and not another one!)
>
> There will be quite a lot of debug output, hence the above
> commandline to copy it also to a file.
>
> It's reasonably likely that the "internal problem in central_filter
> router"
> line results from a subprocess dying, and that the "bad memory
> allocation"
> line is in that subprocess (when that is logged, the process doing
> so dies voluntarily).
