You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by NFN Smith <wo...@sacbeemail.com> on 2008/03/27 19:34:32 UTC
tmp file handling
I'm currently running spamassassin 3.2.1-1~bpo.1 from the Debian
etch-backports branch (yes, I know that backports now has 3.2.4
available, and I'll be upgrading shortly).
On my installation, I'm calling SpamAssassin from MIMEDefang, and so I'm
not running spamc and spamd .
I just discovered that over the last several weeks, I'm getting an
accumulation of hidden .spamassassin temporary files accumulating in
/tmp, that aren't getting deleted, and as a result, that volume is
filling up.
I'm not aware of any operational changes that have been made, so this
one is puzzling.
I can easily set a cron job to find and discard the accumulation, but
I'd prefer to find the source of why these files are getting left in
/tmp, and fix the problem, rather than simply managing the symptoms.
Any idea of why this might be happening?
Smith
Re: tmp file handling
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 27.03.08 11:34, NFN Smith wrote:
> I'm currently running spamassassin 3.2.1-1~bpo.1 from the Debian
> etch-backports branch (yes, I know that backports now has 3.2.4
> available, and I'll be upgrading shortly).
Just FYI:
Debian volatile archive has 3.2.3 and 3.2.4 was planned. Unlike backports,
volatile is officially supported by debian.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #99999: Out of error messages.
Re: tmp file handling
Posted by NFN Smith <wo...@sacbeemail.com>.
Kris Deugau wrote:
> NFN Smith wrote:
>>
>> I'll check the MD archives for release notes, and see what's in the
>> Testing branch.
>
> Just checked the changelog; there was a fix for this in MD 2.63 upstream:
Yep. I found that shortly after I posted.
> Backporting the Debian package should be a matter of snagging the source
> from testing or unstable and rebuilding on stable. I'd suggest unstable
> unless it has bizarre dependencies on too many things.
>
> You might also check the "volatile" repository; there might be a newer
> MD in there. (As well as SA, come to think of it.)
In Debian, 2.64-1 are the current versions in both Testing and Unstable.
As a general rule, I try to not use stuff from Unstable on working
servers. I checked, and there's updates for SA at volatile.debian.org,
but not for MD.
For now, I think getting MD 2.64-1 from Testing will do what I need.
Thanks for the responses.
Smith
Re: tmp file handling
Posted by Kris Deugau <kd...@vianet.ca>.
NFN Smith wrote:
> Hmmm... So this may be an issue with MIMEDefang.
>
> The Debian release number of MIMEDefang I'm running is 2.57-5. It may
> be that when Debian froze what went into etch, the current copy of MD
> was the one with that glitch in it.
>
> I'll check the MD archives for release notes, and see what's in the
> Testing branch.
Just checked the changelog; there was a fix for this in MD 2.63 upstream:
2007-08-13 David F. Skoll <df...@roaringpenguin.com>
* VERSION 2.63 RELEASED
....
* mimedefang.pl.in(spam_assassin_status): Call $mail->finish()
to prevent temporary files from accumulating.
....
Backporting the Debian package should be a matter of snagging the source
from testing or unstable and rebuilding on stable. I'd suggest unstable
unless it has bizarre dependencies on too many things.
You might also check the "volatile" repository; there might be a newer
MD in there. (As well as SA, come to think of it.)
-kgd
Re: tmp file handling
Posted by Kelson <ke...@speed.net>.
NFN Smith wrote:
> The Debian release number of MIMEDefang I'm running is 2.57-5. It may
> be that when Debian froze what went into etch, the current copy of MD
> was the one with that glitch in it.
>
> I'll check the MD archives for release notes, and see what's in the
> Testing branch.
The fix went into MIMEDefang 2.63. That's only one release back (the
latest is 2.64), so you might want to look into the 2.64 changes while
you're at it.
Relevant section from the 2.63 changelog:
> mimedefang.pl.in(spam_assassin_status): Call $mail->finish() to
> prevent temporary files from accumulating.
http://mimedefang.org/node.php?id=64
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: tmp file handling
Posted by NFN Smith <wo...@sacbeemail.com>.
Jason Bertoch wrote:
>> I just discovered that over the last several weeks, I'm getting an
>> accumulation of hidden .spamassassin temporary files accumulating in
>> /tmp, that aren't getting deleted, and as a result, that volume is
>> filling up.
>
>
> There was a version upgrade to SpamAssassin some time ago that broke the way
> MIMEDefang was handling those files. David released a new version of MD
> shortly thereafter that fixed the issue.
Hmmm... So this may be an issue with MIMEDefang.
The Debian release number of MIMEDefang I'm running is 2.57-5. It may
be that when Debian froze what went into etch, the current copy of MD
was the one with that glitch in it.
I'll check the MD archives for release notes, and see what's in the
Testing branch.
Thanks for the tip.
Smith
RE: tmp file handling
Posted by Jason Bertoch <ja...@electronet.net>.
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of NFN Smith
Sent: Thursday, March 27, 2008 2:35 PM
To: users@spamassassin.apache.org
Subject: tmp file handling
>I'm currently running spamassassin 3.2.1-1~bpo.1 from the Debian
>etch-backports branch
>
>On my installation, I'm calling SpamAssassin from MIMEDefang, and so I'm
>not running spamc and spamd .
>
>I just discovered that over the last several weeks, I'm getting an
>accumulation of hidden .spamassassin temporary files accumulating in
>/tmp, that aren't getting deleted, and as a result, that volume is
>filling up.
There was a version upgrade to SpamAssassin some time ago that broke the way
MIMEDefang was handling those files. David released a new version of MD
shortly thereafter that fixed the issue.
Jason A. Bertoch
Network Administrator
jason@electronet.net
Electronet Broadband Communications
3411 Capital Medical Blvd.
Tallahassee, FL 32308
(V) 850.222.0229 (F) 850.222.8771