On 3/25/2017 12:45 PM, Jeremy Harris wrote:
On 25/03/17 18:51, Phillip Carroll wrote:
After only a couple of days running the 4.88-3.el7 build, I accidentally
discovered that it was filling up /var/spool/exim/input with a massive
number of 4K -D files. There were no other files in the spool, only -D.
Lacking -H files, routine checks showed an empty queue.
Do the messages match Bug 2029? That was leaving orphan -D files
in the spool.
Jeremy,
My segfaults don't seem to match your description of bug 2029. I sort of
assumed something to do with chunking. My exim.conf says nothing about
chunking. They switched the default to no chunking in 4.89 build, but
had it set to use chunking in 4.88.
My segfault messages look like this:
exim[8588]: segfault at 0 ip 000055ef14d00011 sp 00007fffe42f1940
error 4 in exim[55ef14c23000+11e000]
(All having identical location description)
In my case I only found lost connections (due to this error) that
involve two server IPs:
12.130.137.235
199.7.206.234
Both these IPs resolve to servers from the same company, but the lost
emails were actually from bulk mailers Staples, Lenovo, Tuesday Morning,
JCPenney, Monoprice, etc.. (identified in the logged connections)
[I tried to create a bugzilla.redhat.com account to report a bug against
the specific EPEL build, but their initial form consistently leads to an
error page that claims "invalid token". Same result on both Firefox and
Chrome, latest versions. Presumably, the bug is upstream from EPEL
anyway, and seems to be fixed by the 4.89 testing release.]
--Phil
--
## 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/
