Re: spamass-milter - solaris vs redhat

[Chuck Yerkes]

I've been having these problems with S.A.M. at a solaris 8
site (compiled with gcc 2.95.3).

I've been debugging a bit on and off.  We've had problems.
500 users (for now), 8000 as a goal.  But we're having these
problems.

With the watchmalloc stuff, the load on a 4x4 E450
(CPU x RAM) shoots up.

I've got some logging from Dan to try, but watchmalloc stuff
seems to be cleaning up (hiding?) the problem.  But the load
is too high.

We're likely going to TRY a linux box (over some objections
cause Solaris as very strong support available here right now
where linux might, later).

There's some string leak, I'm sure.  I'm stopping 8 bit mail
from passing through (just in case).  I just don't know/trust
the gcc++ string routines well enough.  What happens when a
body has a \0 in it? Does free() do the right thing?


Don't OVER limit sendmail - make sure there is a problem
you are sheltering from.  milter timeouts will be an indication
of problems - but look for scans that take > 2-3min in general.
THEN throttle back.

Quoting Hannu Liljemark (address@hidden):
> Heya folks,
> 
> we've been running spamass-milter 0.1.3a with SA 2.5x on
> Solaris 8 at two small sites, both with few thousand mails
> per week (<50 users on both sites). We're thinking about
> setting up similar environments but on a bigger scale.
> 
> I've looked into most of the available milters, and
> spamass-milter seems pretty much the only sane solution
> out there: body replacing, subject rewriting,
> possible to redirect spam to some mailbox/address (0.1.3a
> with "patch 411", or latest cvs), not
> a mimedefang/mailscanner type of thing, works nicely
> on a mail gateway infront of internal mail server or
> whatever (not limited just to local delivery) and, well,
> doesn't come up with anything bizarre but just works
> like plain spamc/spamd.
> 
> Anyways, there seems to be discussion about message corruption
> in Solaris and other weird situations. I don't think we've
> had that problem - at least users haven't reported anything
> - but another problem seems to be spamass-milter process
> crashing, and getting bloated over time:
> 
> % ps -eo user,pid,rss,vsz,nice,nlwp,etime,args|grep spamass-milter
> spamd 25796 57112 68560 20    6  1-02:07:14 
> /opt/spamass-milter/sbin/spamass-milter -p 
> /var/spool/spamassassin/spamass.sock
> 
> That had been running for a days (spamass-milter 0.1.3a).
> 
> 'gcore' output on some earlier process:
> 
> % ls -l core.11202
> -rw-r--r--   1 root     other    134828140 Jun 11 11:35 core.11202
> 
> 130MB. That ran for a few days :-) (Probably not much use in
> analysing that, it's not a crash coredump but done with gcore.
> I guess there's some difference?)
> 
> As I'm updating this mail, the size is 65MB and it was steady
> 11MB over the weekend.
> 
> spamass-milter has crashed occasionaly, but I'm not sure if
> the process grew that big those times and I haven't let the
> process run for long when I've noticed it has gotten that
> huge.
> 
> Another system runs 0.3.1a with "patch 411" and -m:
> 
> % ps -eo user,pid,rss,vsz,nice,nlwp,etime,args|grep spamass-milter
> spamd 10212 17432 19352 20    4  6-01:40:21 
> /opt/spamass-milter/sbin/spamass-milter -b spamd -m -p 
> /var/spool/spamassassin/
> 
> That's a little old status output, but it's been running for
> ten days now and the size at 20MB is reasonable... leaking,
> I guess, but reasonable :-) So with -m spamass-milter seems
> to be quite stable, but I'm not too happy about users insisting
> on having the spam stay on the server (with -b the -m seems to
> be a nice addition, no need to touch the mails much if they
> stay on the server anyway), so just sticking -m in the
> initscript isn't nice (it's ok for that specific site, though).
> 
> What else... Solaris 8, spamass-milter is compiled with gcc
> 2.95.3 and whatever comes with Solaris or on the Companion CD.
> 
> We've set limits on sendmail
> 
> define(`confMAX_DAEMON_CHILDREN', `12')dnl
> 
> to protect the poor Netra X1 boxes the systems run on and
> spamd is started with -m 20. There were some issues with
> things getting out of hands during a flood of messages, but
> those took care of it.
> 
> Something else I noticed (and it was discussed on the list):
> some mails seem to make spamc/spamd and maybe spamass-milter
> go crazy.