Jason Axley wrote:
For me, this is completely reproducible based on the messages in the mail
queue.  I've saved the postfix queue files that caused the problems.  Once
I nuke those from the queue and flush the queue, dspam will work fine
until a similar message comes in.  If anyone's interested in them for test
vectors, let me know.  I wrote a script that would flush individual
messages and pause between, then check to see if they were still in the
queue so I could find out which messages were causing dspam to crash.

My server is not memory-bound and doesn't run that high of a load when the
problem occurs.

Since this was a production machine, I don't have the luxury of running a
debugger on it to find out why dspam was crashing (although I'd like it if
dspam had better debug logging for things unrelated to the Bayesian
filtering, such as what config parameters it is running under, how it
handled the message after it was processed (e.g. connected to
localhost:10025 and here is the SMTP transcript).  It's impossible to know
what it is doing otherwise.  I had to run netcat on port 10025 to find out
that dspam wasn't connecting to this port (unrelated problem that turned
out to be a config error on my part).  But I shouldn't have to do that ;-)

So, I gave upgrading to dspam 3.8.0 a shot and that seems to handle
whatever is thrown at it.  I manually created new packages based on some
existing work out there.  I can't believe debian and ubuntu haven't
upgraded to 3.8.0 yet.  I haven't seen any known problems with 3.8.0 that
would prevent them from upgrading.  I've been running it all weekend with
no problems -- and that's saying something!

FYI, here's a writeup of what I did to upgrade on ubuntu: http://juxtaposition.axley.net/archives/2007/11/postfix_dspam_3_1.html

-Jason

Jason Axley wrote:
Every once in a while, I get some message in my postfix mail queue
that causes dspam to crash.  There isn't any error or indication in
the debug logfile, which I have enabled.  This causes mail messages to
queue up since postfix can't access the dspam socket.  But restarting
dspam and running postqueue -f to flush the mail queue causes dspam to
crash again as it hits the same message again.

How can I debug what and where dspam is crashing at?  Is this a known
issue in this version?  Does 3.8 offer a fix?
I've had exactly the same symptoms (on same versions) except that
restarting did not immediately crash again; therefore this is probably
unrelated (especially given your comments in subsequent messages to this
list), but in our case the machine was running low on RAM and increasing
the RAM solved the problem.

We reached the point of having a script that grepped the output of ps
for the presence of dspam and restarted dspam/postfix/clamav if not
present, then emailed us to tell us it had happened. The script was
triggering once every day or so before the memory upgrade, never since.

--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG


!DSPAM:4,474aab8232572080552694!





Some people (myself included) discovered a problem with DSpam 3.6.8. If DSpam were setup with MySQL and a Merged Group the daemon would segfault. If the merged group was removed the daemon ran without error. I'm unsure what was causing the error, but some reported that the segfault would occur on messages containing foreign language characters. I was never able to verify this.

I'm happy to report that after upgrading to DSpam 3.8.0 the Merged Group segfault seems to be fixed.

Not sure if this was your exact problem, but I'm glad to hear that 3.8.0 is working well for you.

-Jeff Harris

Reply via email to