I'm assuming that Jason Bertoch isn't reporting the same problem with
two different setups (and that MD is omitting the call like spampd).
Looking at the MD list archives now, he's running MD 2.62 and referenced
bug 5444.
Daryl
Justin Mason wrote:
you sure? I don't see anything in that bug mentioning Mimedefang so
far... it seems very likely, though.
--j.
Daryl C. W. O'Shea writes:
It's bug 5444. Mimedefang needs to call Mail::SA::Message->finish().
Daryl
Justin Mason wrote:
hopefully they'll open a bug about it...
--j.
Kevin A. McGrail writes:
Just an FYI. I know nothing more about the issue:
----- Original Message -----
From: "Frank Doepper" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2007 8:27 AM
Subject: Re: [Mimedefang] SA 3.2.0 and tmp files
Am 04.05.2007 19:18 schrieb Kelson:
Jason Bertoch [Electronet] wrote:
To the point...since upgrading to 3.2.0, I'm seeing non-text temp
files being
left behind by SA. They aren't left for every message; most are
created and
destroyed as expected. Unfortunately, the data contained within does
not
contain any information I can tie to a specific message type or case.
Other
than filling up my /tmp space, I see no mail flow problems. Is anyone
else
seeing these temp files left behind?
Hmm, no signs of that problem here, and we upgraded on Wednesday.
Not sure if it matters, but our MD initscript sets TMPDIR to point to
our spool directory, which is on tmpfs. I've checked both the spooldir
and /tmp just to be sure.
MD 2.62, SA 3.20, Sendmail 8.13.8 on Mandriva 2007.
The problem is even worse at our site, we have mimedefang-multiplexor
running with "-l" and get
Slave 5 stderr: seek() on closed filehandle $tmpfile at
/usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Message/Node.pm line 305.
when there is a little bit load on the box. Is it because SA is not
thread-safe? How to solve this?
mimedefang-2.52, SA 3.2.0, sendmail-8.13.6 running.
The behaviour started with upgrade from SA-3.1.7 to SA-3.2.0.
Thanks,
Frank.
