You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2007/05/08 11:35:25 UTC

Re: Fw: [Mimedefang] SA 3.2.0 and tmp files

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" <mi...@taz.de>
> To: <mi...@lists.roaringpenguin.com>
> 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.

Re: Fw: [Mimedefang] SA 3.2.0 and tmp files

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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" <mi...@taz.de>
>> To: <mi...@lists.roaringpenguin.com>
>> 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.
> 


Re: Fw: [Mimedefang] SA 3.2.0 and tmp files

Posted by "Kevin A. McGrail" <ke...@thoughtworthy.com>.
I've requested that at least one of them does and will try and follow up on 
it.

----- Original Message ----- 
From: "Justin Mason" <jm...@jmason.org>
To: "Kevin A. McGrail" <km...@pccc.com>
Cc: "SpamAssassin Dev" <de...@spamassassin.apache.org>
Sent: Tuesday, May 08, 2007 5:35 AM
Subject: Re: Fw: [Mimedefang] SA 3.2.0 and tmp files


>
> 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" <mi...@taz.de>
>> To: <mi...@lists.roaringpenguin.com>
>> 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.
>