[exim] exim doesn't seem to properly clean up after exhausin…

Top Page

Reply to this message
Author: Russell King
Date:  
To: exim-users
Subject: [exim] exim doesn't seem to properly clean up after exhausing spool space
Hi,

It seems that exim doesn't properly clean up after a failure to write
to its message queue, but ends up leaving what it has written in the
spool and other directories.

The sending server (exim) reported:

2019-12-14 12:53:58 1ig6vR-0003NP-2l <= rmk@??? U=rmk P=local S=14483755 id=<elided>@gmail.com
2019-12-14 12:54:28 1ig6vR-0003NP-2l H=mail.armlinux.org.uk [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after end of data: 451 Temporary local problem - please try later

after it tried to deliver a message, because mail.armlinux.org.uk ran
out of space (oops.) A 14MB email tends to be the exception here.

On mail.armlinux.org.uk (debian buster, 4.92-8+deb10u3):

2019-12-14 12:54:23 1ig6vq-00073k-Ez H=flint.armlinux.org.uk [x:x:x:x:201:2ff:fe14:8fad] Warning: ACL "warn" statement skipped: condition test deferred
... repeated several times ...
2019-12-14 12:54:28 1ig6vq-00073k-Ez malware acl condition: clamd /run/clamav/clamd.ctl : ClamAV returned: /var/spool/exim4/scan/1ig6vq-00073k-Ez/1ig6vq-00073k-Ez.eml: Can't create temporary directory ERROR

It looks like this occasion was properly cleaned up. Then the sending
server had another couple of goes using some of the other addresses for
the server (different IPv6 prefixes):

2019-12-14 12:54:43 1ig6vR-0003NP-2l H=mail.armlinux.org.uk [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after end of data: 421 Unexpected failure, please try later
2019-12-14 12:54:44 1ig6vR-0003NP-2l H=mail.armlinux.org.uk [x:x:x:x:5054:ff:fe00:189]: SMTP error from remote mail server after pipelined MAIL FROM:<rmk@???> SIZE=14672979: 421 Unexpected failure, please try later

For the second attempt, mail.armlinux.org.uk logged:

2019-12-14 12:54:43 1ig6wH-00073p-Mu H=flint.armlinux.org.uk [x:x:x:x:201:2ff:fe14:8fad] Warning: ACL "warn" statement skipped: condition test deferred
... repeated several times ...
2019-12-14 12:54:43 1ig6wH-00073p-Mu H=flint.armlinux.org.uk [x:x2019-12-14 13:02:56 Start queue run: pid=27196 -qfl

Note the last log line was corrupted, which suggests exim couldn't write
to the log file (space was available but only as reserved for root.)
However, note the spool ID.

At this point, mail.armlinux.org.uk stopped receiving anything else:

2019-12-14 13:04:26 spool directory space check failed: space=0 inodes=353381

as the space that that previous attempt left a bunch of files behind:

-rw-r----- 1 Debian-exim Debian-exim 14479989 Dec 14 12:54 /var/spool/exim4/input/1ig6wH-00073p-Mu-D

without a -H file, so exim is never going to process that. Also:

# ls -al /var/spool/exim4/scan/1ig6wH-00073p-Mu/
-rw-r----- 1 Debian-exim Debian-exim 14479970 Dec 14 12:54 1ig6wH-00073p-Mu-00000
-rw-r----- 1 Debian-exim Debian-exim        3 Dec 14 12:54 1ig6wH-00073p-Mu-00001
-rw-r----- 1 Debian-exim Debian-exim  1867851 Dec 14 12:54 1ig6wH-00073p-Mu-00002
-rw-r----- 1 Debian-exim Debian-exim        5 Dec 14 12:54 1ig6wH-00073p-Mu-00003
-rw-r----- 1 Debian-exim Debian-exim   819200 Dec 14 12:54 1ig6wH-00073p-Mu-00004
-rw-r----- 1 Debian-exim Debian-exim        0 Dec 14 12:54 1ig6wH-00073p-Mu-00005
-rw-r----- 1 Debian-exim Debian-exim        0 Dec 14 12:54 1ig6wH-00073p-Mu-00006
-rw-r----- 1 Debian-exim Debian-exim        0 Dec 14 12:54 1ig6wH-00073p-Mu-00007
-rw-r----- 1 Debian-exim Debian-exim        0 Dec 14 12:54 1ig6wH-00073p-Mu-00008
-rw-r----- 1 Debian-exim Debian-exim        0 Dec 14 12:54 1ig6wH-00073p-Mu-00009
-rw-r----- 1 Debian-exim Debian-exim 14484031 Dec 14 12:54 1ig6wH-00073p-Mu.eml


were all left behind from that attempt.

I'm going to provision a separate filesystem for exim's spool for the
future, but the obvious question is - shouldn't exim have cleaned up
after itself, rather than leaving large stale files behind?

I guess the plus point of leaving the files behind is it creates a
hard failure that gets noticed!

Thanks.

--
Russell King