Bug 6033

Summary:	[review] kill_handler should exit with non-zero status
Product:	Spamassassin	Reporter:	kevin Atkinson <kevin.sabug>
Component:	spamassassin	Assignee:	SpamAssassin Developer Mailing List <dev>
Status:	RESOLVED FIXED
Severity:	critical	CC:	apache
Priority:	P2
Version:	3.2.5
Target Milestone:	3.2.6
Hardware:	All
OS:	All
Whiteboard:	ready to commit
Attachments:	patch for 3.2.x

Description kevin Atkinson 2008-12-18 19:37:26 UTC

In spamassassin "kill_handler" exits with a zero status code.  This is very bad as it can cause mail to get lost when used with procmail.  It should exit with some non-zero status or reraise the signal so that procmail will get some indication that spamassassin did not complete successfully so that it can rescue the mail.

In my particular case, due to some bug, spamassassin was getting a SIGPIPE for some reason and I was getting a blank mail message.

Made the severity critical since this bug can cause loss of data.

Comment 1 Justin Mason 2008-12-19 01:54:41 UTC

yes. definitely, this should be an error exit code. not sure how that got past...

Comment 2 Rasmus Skaarup 2008-12-26 13:12:20 UTC

Yes, indeed. I'm struck by this bug as well. Blank emails (zero-sized files in my Maildir) started showing up.

The following information was available in the qmail logs:

delivery 16346: success: [71557]_warn:_spamass:_fik_en_sigpipe!/[71557]_warn:_razor2:_razor2_check_failed:_No_such_file_or_directory_razor2:_razor2_had_unkno
wn_error_during_get_server_info_at_/usr/local/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/Plugin/Razor2.pm_line_188._at_/usr/local/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/Plugin/R
azor2.pm_line_326./did_0+0+1/

As you can see qmail determines that it was a "success" because of the normal exit code from SpamAssassin.

For informational purposes I now provide the output from Razor, since the Razor-plugin was the culprit:

Dec 26 20:52:17.586908 check[71557]: [ 2] [bootup] Logging initiated LogDebugLevel=5 to file:razor-agent.log
Dec 26 20:52:17.587441 check[71557]: [ 5] computed razorhome=, conf=, ident=identity
Dec 26 20:52:17.588375 check[71557]: [ 5] Can't read file /servers.discovery.lst: No such file or directory
Dec 26 20:52:17.588545 check[71557]: [ 5] Can't read file /servers.nomination.lst: No such file or directory
Dec 26 20:52:17.588705 check[71557]: [ 5] Can't read file /servers.catalogue.lst: No such file or directory
Dec 26 20:52:17.588901 check[71557]: [ 5] no listfile: servers.catalogue.lst
Dec 26 20:52:17.589107 check[71557]: [ 5] Connecting to discovery.razor.cloudmark.com ...
Dec 26 20:52:17.785213 check[71557]: [ 4] discovery.razor.cloudmark.com >> 0 server greeting:
Dec 26 20:52:17.785362 check[71557]: [ 4] discovery.razor.cloudmark.com << 12
Dec 26 20:52:17.785597 check[71557]: [ 5] _read: connection_closed

Pay notice to the missing "server greeting".

That caused a "No such file or directory" error from SpamAssasin - not very helpful. 

A normal logfile output from Razor looks like this for me:

Dec 26 21:49:32.538759 check[83113]: [ 2] [bootup] Logging initiated LogDebugLevel=5 to file:razor-agent.log
Dec 26 21:49:32.546787 check[83113]: [ 5] computed razorhome=, conf=, ident=identity
Dec 26 21:49:32.547497 check[83113]: [ 5] Can't read file /servers.discovery.lst: No such file or directory
Dec 26 21:49:32.547648 check[83113]: [ 5] Can't read file /servers.nomination.lst: No such file or directory
Dec 26 21:49:32.547791 check[83113]: [ 5] Can't read file /servers.catalogue.lst: No such file or directory
Dec 26 21:49:32.547971 check[83113]: [ 5] no listfile: servers.catalogue.lst
Dec 26 21:49:32.548159 check[83113]: [ 5] Connecting to discovery.razor.cloudmark.com ...
Dec 26 21:49:33.199625 check[83113]: [ 4] discovery.razor.cloudmark.com >> 35 server greeting: sn=D&srl=570&a=1&a=cg&ep4=7542-10^M
Dec 26 21:49:33.199783 check[83113]: [ 4] discovery.razor.cloudmark.com << 12
Dec 26 21:49:33.295701 check[83113]: [ 4] discovery.razor.cloudmark.com >> 71
Dec 26 21:49:33.295903 check[83113]: [ 4] discovery.razor.cloudmark.com << 12
Dec 26 21:49:33.390551 check[83113]: [ 4] discovery.razor.cloudmark.com >> 91
Dec 26 21:49:33.390773 check[83113]: [ 5] disconnecting from server discovery.razor.cloudmark.com
Dec 26 21:49:33.390869 check[83113]: [ 4] discovery.razor.cloudmark.com << 5

As you can see "discovery.razor.cloudmark.com" now responds just fine.

This is just for informational purposes. I've been searching the web high and low for a solution. But SpamAssassin should by all means NOT exit with a normal exit code - this has caused me to loose emails!

Comment 3 Justin Mason 2008-12-29 02:55:45 UTC

committed to trunk:

: 58...; svn commit -m "bug 6033: spamassassin script should exit with non-zero status if killed using SIGHUP, SIGTERM, SIGINT or SIGPIPE" spamassassin.raw 
Sending        spamassassin.raw
Transmitting file data .
Committed revision 729860.

here's a patch for 3.2.x...

Comment 4 Justin Mason 2008-12-29 02:58:24 UTC

Created attachment 4411 [details]
patch for 3.2.x

please vote for inclusion in 3.2.x...

Comment 5 Sidney Markowitz 2008-12-29 04:10:17 UTC

+1 for putting this in 3.2

Comment 6 Rasmus Skaarup 2008-12-29 04:43:52 UTC

Not sure how to vote - but I defintely vote for it to be included in 3.2.x.

@vote

Comment 7 Mark Martinec 2009-01-05 17:06:01 UTC

+1

Comment 8 Justin Mason 2009-03-29 12:38:54 UTC

(In reply to comment #4)
> Created an attachment (id=4411) [details]
> patch for 3.2.x
> 
> please vote for inclusion in 3.2.x...

: 360...; svn commit -m "bug 6033: spamassassin script should exit with non-zero
: 361... >>; status if killed using SIGHUP, SIGTERM, SIGINT or SIGPIPE" spamassassin.raw
Sending        spamassassin.raw
Transmitting file data .
Committed revision 759764.