reminder from bug 5444: if the calling code calls $permsgstatus->finish(), then
we may have a bug to fix in SA.

otherwise, the calling code needs to be fixed to call ->finish(), which has been
required (but unenforced until now) since SA 3.0.0.

I've got similar issues on my FreeBSD system.

-rw-------  1 mailnull  wheel  13110 Aug 12 21:34 /tmp/.spamassassin89241ESdKdwtmp
-rw-------  1 mailnull  wheel  23161 Aug 12 11:05 /tmp/.spamassassin89241FYNO81tmp
-rw-------  1 mailnull  wheel  13110 Aug 12 21:34 /tmp/.spamassassin89241JGI9jEtmp
-rw-------  1 mailnull  wheel   7336 Aug 12 18:57 /tmp/.spamassassin89241JgFEbXtmp
-rw-------  1 mailnull  wheel  19150 Aug 13 05:35 /tmp/.spamassassin89241JkL0aptmp
-rw-------  1 mailnull  wheel  24154 Aug 13 06:23 /tmp/.spamassassin89241KIeq7Htmp
-rw-------  1 mailnull  wheel  20348 Aug 12 04:01 /tmp/.spamassassin89241LPCXBdtmp
-rw-------  1 mailnull  wheel  24154 Aug 13 06:23 /tmp/.spamassassin89241QJElAdtmp
-rw-------  1 mailnull  wheel  37313 Aug 13 03:48 /tmp/.spamassassin89241Qm44Outmp
-rw-------  1 mailnull  wheel  41771 Aug 13 03:48 /tmp/.spamassassin89241TQHQXltmp
-rw-------  1 mailnull  wheel  41771 Aug 13 03:48 /tmp/.spamassassin89241W5I2lCtmp
-rw-------  1 mailnull  wheel  18818 Aug 12 19:49 /tmp/.spamassassin89241WEFYgftmp
-rw-------  1 mailnull  wheel   7336 Aug 12 18:57 /tmp/.spamassassin89241kzMXrjtmp
-rw-------  1 mailnull  wheel  23161 Aug 12 11:05 /tmp/.spamassassin89241ozlyuVtmp
-rw-------  1 mailnull  wheel  18818 Aug 12 19:49 /tmp/.spamassassin89241u26x6Atmp
-rw-------  1 mailnull  wheel  19150 Aug 13 05:35 /tmp/.spamassassin89241wZHM8Rtmp
-rw-------  1 mailnull  wheel  37313 Aug 13 03:48 /tmp/.spamassassin89241xYqRfytmp
-rw-------  1 mailnull  wheel  20348 Aug 12 04:01 /tmp/.spamassassin89241yhTyPOtmp

Issue started when I installed SA version 3.2.1.

OS: FreeBSD server 6.2-RELEASE-p5 FreeBSD 6.2-RELEASE-p5 #4: Thu May 31 10:58:52
CEST 2007

same thing happens with a standard SA 3.2.2 installation on debian.

R, Thomas --

how are you calling SA?   directly via procmail and spamc, or with Amavis, Exim,
Mailscanner, etc.?  Is there any process that could be killing the spamd
processes  with kill -9 or kill -15?

We are calling spamassassin from our SMTP proxy directly
"spamassassin -x -c ruleset -e 255"
(no spamc/spamd).
The temp file issue seems to have started with SA 3.2.0.

yeah, 3.2.0 normalizes the temp file behaviour cross-platform, so behaviour that
would be buggy on win32 is now buggy on all platforms, for consistency. ;)

Do you ever interrupt a running spamassassin process?

Yes, this happens from time to time e.g. when a sending MTA disconnects
unexpectedly.
We did not have any problems doing this with pre-3.2.0 SA releases.
It would be great if you could give us some more details on the temp file
behaviour related changes in the 3.2 release.
Is there anything we can do to make SA clean up its temp files under these
conditions, e.g. another way to terminate a running SA? I can imagine that other
SA users also have this issue.

Per Kristian Hove, via mail, noted:


'Hi, I apologize for sending this directly to you, but
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5557 didn't let
me provide input without registering, which I at the moment don't have
time to do. (Also, if you forward this information to somebody, please
leave out my email address. Thanks in advance).

We see similar issues on Solaris 8 with SpamAssassin 3.2.3 invoked as
a filter from ".qmail" files (no spamd/spamc configuration, only a
single message per invocation of spamassassin).

This happens when spamassassin dies with SIGPIPE, which seems to
happen occationally. Could the reason be an internal bug in
spamassassin? (When dying with SIGPIPE, it doesn't get the chance to
run the cleanup-on-exit procedures). No other filters invoked from
.qmail have this problem, so the cause of the SIGPIPE is unlikely to
be the pipe that spamassassin gets from qmail as stdin.

Also, in most (but not all) of the cases, the temp files left behind
appears in pairs: there are often 2 temp files created by the same
process:

-rw-------  1 xxx      xxx    54642 Aug 23 11:10 .spamassassin20499BnIaSstmp
-rw-------  1 xxx      xxx    71048 Aug 23 11:10 .spamassassin20499Z5fMKptmp

etcetera.


-- 
Per Kristian Hove <....>
Chief engineer, Dept. of Mathematical Sciences
Norwegian University of Science and Technology'

(In reply to comment #8)
> We see similar issues on Solaris 8 with SpamAssassin 3.2.3 invoked as
> a filter from ".qmail" files (no spamd/spamc configuration, only a
> single message per invocation of spamassassin).
> 
> This happens when spamassassin dies with SIGPIPE, which seems to
> happen occationally. Could the reason be an internal bug in
> spamassassin? (When dying with SIGPIPE, it doesn't get the chance to
> run the cleanup-on-exit procedures). No other filters invoked from
> .qmail have this problem, so the cause of the SIGPIPE is unlikely to
> be the pipe that spamassassin gets from qmail as stdin.

this is now opened (separately) as bug 5626.

This bug (on Windows at least) happens because the temp files are not closed 
before deletion is attempted.

Non-text mime parts are stored in temp files, and these files are not closed in 
the finish() code in message.pm before they are deleted.
Adding:

    if (ref $part->{'raw'} eq 'GLOB') {
      # Make sure the file is closed it if it's a temp file -- Bug 5557
      close ($part->{'raw'});
    }

to the cleanup of Message::Node part in finish() and moving:

  # delete temporary files
  if ($self->{'tmpfiles'}) {
    unlink @{$self->{'tmpfiles'}};
    delete $self->{'tmpfiles'};
  }

to the end of finish() fixes the problem.
Bug 5626 is probably not related to this bug.

(In reply to comment #10)
> This bug (on Windows at least) happens because the temp files are not closed 
> before deletion is attempted. [...]

Thanks, that seems likely to be it!  well spotted.

I'll attach that fix as a patch -- would appreciate if you/others could try it
out and report if it works for you.

Created attachment 4125 [details]
fix as patch

applied to 3.3.0 trunk as r576895.

oops -- not fixed!  this is still an issue for 3.2.x, and needs confirmation
that the fix as applied *works*.

(In reply to comment #14)
> oops -- not fixed!  this is still an issue for 3.2.x, and needs confirmation
> that the fix as applied *works*.

I can confirm that it works under Windows. No temp files are being left anymore.

Confirmed here, too -- that patch fixes the problem on Win32 and temporary files
are no longer left around.

+1

+1

added to 3.2.x: r604715

On both Linux and Windows some temp files are still not removed when
spamassassin receives a signal. 
Adding 

  if (defined $tempfile) {
    unlink $tempfile;
    $tempfile = undef;
  }

at the end of kill_handler in the spamassassin script helps, but temp files
created through

my $tmpf = $permsgstatus->create_fulltext_tmpfile($fulltext);

in dccproc_lookup (line 526 in the DCC.pm plugin) will still not be cleaned up
properly.
Any ideas to resolve this?

(In reply to comment #20)
> On both Linux and Windows some temp files are still not removed when
> spamassassin receives a signal. 

please open this as a new issue. thanks!

re-closing, as noted, please open a new issue.

I've checked in the quick 4-line fix for kill_handler, though, to
svn trunk...

: jm 406...; svn commit -m "bug 5557: additional tempfile cleanup in
kill_handler part of spamassassin script" spamassassin.raw
Sending        spamassassin.raw
Transmitting file data .
Committed revision 620609.