Re: spamass-milter stops working under heavy load

[Dan Nelson]

In the last episode (Jun 17), address@hidden said:
> indeed the behaviour is as described. We started a quick and dirty
> solution to count the number of running spamass-milter and restart if
> it's lower than 3. We just had it active for 4 hours or so and had
> one restart event. We'll observe this during working hours the next
> days.
>
> We are stuffed with projects at the moment to only minimal time to
> figure out what's really going one here. We'll see if I can get a
> coredump from the crash. Do you expect this problem to be caused by a
> single mail or do we have a race- condition or similar here, so
> replication on other systems of the problem is extremly difficult?

I don't think it's a race condition; all of the per-connection data
should be in a private object, and I shouldn't be using any
thread-unsafe libc functions.  You can try running it under valgrind
--skin=helgrind, though.  That's supposed to catch some thread race
problems.

> If so, that I might try to "record" the SMTP traffic and try to catch
> one of the problem mails. I've no idea how to get this done at the
> moment, but maybe there is an option to do this.

A quick hack would be to run "tcpdump -w file.tcp -s 1500 port 25" on the
mailserver, log its pid into a file, and if your restart script notices
that the milter has died, have it run "kill -INT $(cat tcpdump.pid)". 
You can use ethereal to extract the tcp stream later.

-- 
        Dan Nelson
        address@hidden