[milters] Archive

Lists Index Date Thread Search

Article: 1817
From: Michael Grant
Date: 2007-12-22 09:47:26 -0500
Subject: Re: SPAMD status line failure

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

On Dec 22, 2007 3:19 PM, Anthony Howe <achowe@snert.com> wrote:
> Michael Grant wrote:
> > I've been seeing this error in my log file using milter-spamc: SPAMD
> > status line failure
> >
> > I get it on messages that are both spam and ham.  It's not happening
> > on all messages, but is happening about once an hour (meaning once
> > every several hundred messages in my case).
> >
> > I'm running SpamAssassin version 3.2.3.
> >
> > Anyone else getting this message?  Is there anything I can do about it
> > to fix it?
>
> This is an I/O error while waiting for the spamd status response line.
> Most typical reason is a timeout error. Consider increasing the
> spamd-timeout value from 120 seconds to something larger. Spamd is
> resource intensive Perl process and is not threaded and will queue up
> connections between spamd child processes.

I don't think it's a quite a timeout issue, the readline() is
returning immediately with an EOF.  However, from the logs, it appears
that spamd does in fact process the message but returns it's result
several seconds (not 2 min) after the status line failure.

Through experimentation, I have discovered that this error only
happens with large messages, particularly messages with large
attachments.  It is definitely related to message size rather than
server load.

I'm wondering if there has been a change at the spamd socket level
between 3.1 and 3.2, perhaps in terms of blocking vs non-blocking i/o.
 It feels like spamd in 3.2 is returning eof in your readline() when
it's not yet finished processing the large message.  I haven't gone
into your code to probe this hypothesis yet.

> If you have high volume of message traffic, also consider increasing the
> number of spamd child processes as the default spamd configuration might
> be insufficient for your load.
>
> Another thing to consider is that SpamAssassin 3.2 from what I'm told
> (I'm still running a 3.1 version so I'm unfamilar with it) can update on
> a regular basis its rulesets. This probably involves restarted the
> parent spamd processes after the update, which would mean some sendmail
> / milter-spamc / spamd connection chains will exhibit an I/O error when
> an active connection disappears. You might want to lengthen the time
> between updates checks to reduce the frequency.

You're right, it does involve a restart, but I'm updating manually for
the moment.

-Mike

Lists Index Date Thread Search