You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2007/02/12 11:59:34 UTC

Re: Mail::SpamAssassin::Client oddities

Gary W. Smith writes:
> > Don't bother with the ping... just try to process the message.  It'll
> > fail just as fast as a ping if the spamd service isn't working.
> 
> I agree that this should be the case.  I have tested it with pointing to
> a dead server in the mix and it still hangs sometimes reports that the
> service is offline. (though I'm watching it on both ends and seeing that
> there is no load on the SA box.
> 
> I failed to mention that my dev environment is a Xen instance on a box
> with a few other instances.  I suspect, but can't confirm, that I might
> be seeing an issue with setting up of TCP connections.  I'm going to
> play around with that for a while to verify.

strace'ing the client side may help a lot, and/or tcpdump.

--j.

> > What sort of failure are you seeing?  Are you seeing "Failed to create
> > connection to spamd daemon: $!" being output on STDOUT, indicating a
> > failure to setup the socket, or something else?  If something else,
> you
> > may want to try logging the response $line in the ping method to see
> > what the response is, if any.  The spamd logs may also provide some
> > clues.
> 
> When the ping fails to access one of the remote active SA instances, no
> logs are recorded.  It's like the call was never answered.  
> > 
> > fwiw, I haven't seen this happen with my check_spamd Nagios plugin,
> > which also works as a command line util, (availble from SA's svn in
> > contrib/).  Nagios consistently reports "OK durations" equal to that
> of
> > other services on the systems that have a spamd service being checked.
> > 
> > I haven't noticed it happen with my milter either, which uses
> > M::SA::Client, but it automatically tries other spamd services until
> it
> > either gets a successful scan or times out.  I haven't noticed too
> many
> > messages that aren't scanned by the primary spamd service for the
> > particular MX (and none that aren't scanned by at most the second
> spamd
> > service for that MX).  So if it is failing when it shouldn't it's
> rare.
> 
> I have an array of instances from a config file that I will be using.
> What I will do is random load balancing and if that fails I might just
> walk the array in order (or come up with some other weighed method of
> doing it).
> 
> BTW, thanks for the info.
> 
> Gary