[Mimedefang] Parser: can't flush: No space left on device and big files in /tmp
mdlist-20140424 at billmail.scconsult.com
Wed Oct 28 20:32:12 EDT 2015
On 28 Oct 2015, at 16:48, Tom Knutson wrote:
> Lately we are seeing this error in the maillog several times a day:
> Oct 28 15:10:03 mail mimedefang-multiplexor: Slave 1 stderr:
> MIME::Parser: can't flush: No space left on device at
> /usr/local/lib/perl5/site_perl/5.8.9/MIME/Parser.pm line 815, <FILE>
> line 2700428.
> The /var drive has plenty of room. The /tmp drive is nearly full with
> 5 large files owned by mailnull:
> -rw------- 1 mailnull wheel 167779519 Oct 28 12:39 qhNzfFSRG3
> If I delete one of these large files in /tmp, they reappear after a
> few minutes.
Any Perl module using File::Temp with default parameters (which can
include MIME::Parser, via MIME::Tools) will create temp files with
10-character random-alphanumeric names in /tmp and if the calling
process is running as mailnull (the default for anything hooked into
sendmail on FreeBSD) they will be owned by mailnull.
> This started about a week ago on a system that has been running OK for
> quite a while.
> FreeBSD 7.1
> Mimedefang 2.64_1
> clamav 0.97.6
> spamassassin 3.3.2
> perl 5.8.9
So you're a fan of 2008? :)
I sincerely hope that machine is well-guarded externally, hardened
internally, poorly publicized, and carefully watched. Note that beyond
the obvious issue of security, those versions of clamav and spamassassin
are substantially disabled by their age.
> I have tried restarting mimedefang.
> Are these big files being created by mimedefang?
Probably so, indirectly. MIME::Parser can create files like that and
will die as you've seen if /tmp fills while it needs to write one. And
to quote from mimedefang.pl itself:
> I didn't think it
> used /tmp by default.
Not directly and implicitly, but indeed it does and so will a lot of
other common Unix gadgets (e.g. mailx, cron, etc.) so if you have a
chronic issue of /tmp filling you will have a chronically and diversely
> Could this problem be caused by cleverly crafted
Possibly. Also possible: very large messages or messages that innocently
catch on one of ~3 dozen bugs fixed in the MIME-Tools suite since the
last version you are likely to have installed, in such a fashion that it
goes insane and fills its temp files to the point of filling /tmp.
> Suggestions on how to troubleshoot this would be appreciated.
I'm torn ethically on offering deep "troubleshooting" suggestions
because I don't think it is in your interest to try to keep that system
running in its antiquated and intrinsically non-securable state. But
here are some vague suggestions, with the caveat that I hope you start
with the last one...
It may be that all you need to do is to configure your MTA to advertise
a sane maximum mail size limit so people stop trying to mail you CD
images. Using mail to transport objects >160MB is not sane. But then,
neither is handling modern Internet mail on a system that hasn't been
updated in 7 years...
Of course, you could also try slapping an extra GB into /tmp to give
MIME::Parser room to blow up even worse OR handle the giant messages.
You could also fiddle with how MD is being launched to put
TMPDIR=/var/tmp into its environment, which should make these beasts go
there (and maybe fill /var for you, breaking so much more)
If you're actually receiving messages that are >160MB intentionally, you
can make them bypass MD content scanning in mimedefang-filter, but I'm
not actually sure if that works for the basic MIME parsing step.
Adding logging code in mimedefang-filter can help nail down which
messages are the cause of the giant files filling /tmp.
Ultimately, you should update to a maintainable OS version (i.e. FreeBSD
9.3 at least) and current versions of all of the other software
More information about the MIMEDefang