Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 155745 - mail-filter/spamassassin-3.1.4 & mail-filter/spamassassin-ruledujour-20051123 problem.
Summary: mail-filter/spamassassin-3.1.4 & mail-filter/spamassassin-ruledujour-20051123...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Perl team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-20 02:31 UTC by Steve Haeck
Modified: 2007-08-03 00:09 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Haeck 2006-11-20 02:31:54 UTC
While I've not (as yet) established exactly what is wrong, I have established that there is a problem.  When RulesDuJour updated my SARE rule-sets it caused spamd to fail to process all subsequent emails until it was restarted with "/etc/init.d/spamd restart".

This is a (sanitised) extract from syslog showing when this problem arose (N.B. spamc continued to fail for several hours until I restarted spamd manually.) :

--
Nov 15 03:20:00 svr fcron[5328]:     process already running: root's
/usr/bin/test -x /usr/sbin/run-crons && /usr/sbin/run-crons
Nov 15 03:20:14 svr postfix/pickup[11065]: ...: uid=0 from=<root>
Nov 15 03:20:14 svr postfix/cleanup[11232]: ...: message-id=...
Nov 15 03:20:15 svr spamd[7808]: spamd: connection from localhost
[127.0.0.1] at port 1125
Nov 15 03:20:15 svr spamd[7808]: spamd: setuid to foouser succeeded
Nov 15 03:20:15 svr spamd[7808]: spamd: processing message .. for
foouser:1000
Nov 15 03:20:18 svr spamd[7808]: spamd: clean message (-2.9/5.0) for
foouser:1000 in 3.1 seconds, 647 bytes.
Nov 15 03:20:18 svr spamd[7808]: spamd: result: . -2 - AWL,BAYES_00
scantime=3.1,size=647,user=foouser,...
Nov 15 03:20:18 svr postfix/local[11237]: ...
Nov 15 03:20:18 svr postfix/qmgr[5607]: ...: removed
Nov 15 03:20:19 svr spamd[5462]: prefork: child states: II
Nov 15 03:20:26 svr postfix/pickup[11065]: ...: uid=0 from=<root>
Nov 15 03:20:26 svr postfix/cleanup[11232]: ...
Nov 15 03:20:27 svr spamd[7808]: spamd: setuid to foouser succeeded
Nov 15 03:20:27 svr spamd[7808]: spamd: processing message ... for
foouser:1000
Nov 15 03:20:29 svr spamd[7808]: spamd: clean message (-2.2/5.0) for
foouser:1000 in 2.7 seconds, 612 bytes.
Nov 15 03:20:29 svr spamd[7808]: spamd: result: . -2 - AWL,BAYES_05
scantime=2.7,size=612,user=foouser,uid=1000,...
Nov 15 03:20:29 svr postfix/local[11237]: EEA5F3B945:
to=<foouser@shic.lan>, orig_to=<root>, relay=local, delay=3, status=sent
(delivered to command: /usr/bin/proc
Nov 15 03:20:29 svr postfix/qmgr[5607]: EEA5F3B945: removed
Nov 15 03:20:30 svr spamd[5462]: prefork: child states: II
Nov 15 03:21:05 svr spamd[5462]: spamd: server killed by SIGTERM,
shutting down
Nov 15 03:21:11 svr rc-scripts: Failed to stop spamd
Nov 15 03:30:00 svr fcron[5328]:     process already running: root's
/usr/bin/test -x /usr/sbin/run-crons && /usr/sbin/run-crons
Nov 15 03:40:00 svr fcron[11746]: Job /usr/bin/test -x
/usr/sbin/run-crons && /usr/sbin/run-crons started for user root (pid 11747)
Nov 15 03:50:00 svr fcron[11759]: Job /usr/bin/test -x
/usr/sbin/run-crons && /usr/sbin/run-crons started for user root (pid 11760)
Nov 15 03:50:24 svr postfix/smtpd[11772]: connect from localhost[127.0.0.1]
Nov 15 03:50:24 svr postfix/smtpd[11772]: ...: client=localhost[127.0.0.1]
Nov 15 03:50:24 svr postfix/cleanup[11775]: ...: message-id=...
Nov 15 03:50:24 svr postfix/qmgr[5607]: 73FAA3B4FB: from=...
Nov 15 03:50:24 svr postfix/smtpd[11772]: disconnect from
localhost[127.0.0.1]
Nov 15 03:50:24 svr spamc[11779]: connect(AF_INET) to spamd at 127.0.0.1
failed, retrying (#1 of 3): Connection refused
Nov 15 03:50:25 svr spamc[11779]: connect(AF_INET) to spamd at 127.0.0.1
failed, retrying (#2 of 3): Connection refused
--

Issuing '/etc/init.d/spamd restart' as root resolved the situation...
but I don't want to have to do this every time a rule-set is
automatically updated overnight.

I enquired about this on both the gentoo user list and the spamassassin user list.  On the latter I got this response:

http://marc.theaimsgroup.com/?l=spamassassin-users&m=116377918014476&w=2

My spamassassin is running on humble hardware when compared with state of the art - however, with the exception of this glitch (which looks, on the surface, like a bug in waiting a static time for a shutdown) my setup performs perfectly for my purposes...
Comment 1 Alexandre Ghisoli 2007-01-28 12:19:59 UTC
(In reply to comment #0)

> Issuing '/etc/init.d/spamd restart' as root resolved the situation...
> but I don't want to have to do this every time a rule-set is
> automatically updated overnight.
> 

You have to restart your spamd ! Look in your /etc/rulesdujour/config
at the bottom of the file :
SA_RESTART="/etc/init.d/spamd restart"

and rulesdujour will auto reload your spamd process.

This is a feature.



Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-02-24 11:51:16 UTC
something is broken in your spamd. rules_du_jour validates the new rules and then restarts the spamd if the rules pass the spamassassin --lint check.
Comment 3 Yuval Hager 2007-05-04 04:56:35 UTC
I experience this problem too..

I do have 'SA_RESTART="/etc/init.d/spamd restart"' on my rulesdujour config file, but still, almost every night (probably when rules are updated) spamd is killed without being reloaded..
Comment 4 Steve Haeck 2007-05-04 12:52:53 UTC
(In reply to comment #3)
> I experience this problem too..
> 
> I do have 'SA_RESTART="/etc/init.d/spamd restart"' on my rulesdujour config
> file, but still, almost every night (probably when rules are updated) spamd is
> killed without being reloaded..
> 

--
# grep SA_RESTART /etc/rulesdujour/config
SA_RESTART="/etc/init.d/spamd restart"
# spamassassin --lint
#
--

So, I do have /etc/init.d/spamd restart in my /etc/rulesdujour/config.
My configuration does pass spamassassin --lint.

I originally reported this problem and it remains a problem.

I've not messed about with the configuration of rulesdujour or spamassassin - it is all vanilla portage stuff.

The only thing that might be unusual about me is that I run my gentoo server on a very low-spec PC - hence if this is some kind of timeout issue, this might exhibit itself more frequently on my configuration.

Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-08-03 00:09:12 UTC
spamassasin-ruledujour will be removed at the start of September. See my email
to gentoo-dev ML.