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. > >
