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).
--
## 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/
