[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

spamass-milter - solaris vs redhat

From: Hannu Liljemark
Subject: spamass-milter - solaris vs redhat
Date: Mon, 16 Jun 2003 21:23:04 +0300
User-agent: Mutt/1.5.4i

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

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.

Ok to the actual question. We were thinking about implementing
site-wide SA on some sites with more users (few thousand).
There'll probably be Redhat on x86 boxes [I don't care as long
as they're beefier than the X1's :-) ]. What I'm wondering is
what kind of environments are you people using spamass-milter,
on what platform and how well does it work? Do people actually
have cronjobs restarting spamass-milter and/or wrappers that
restart it when it dies?

Great software, I wish I could do something to help. I don't
have much clue about the watchmalloc stuff discussed on the list
other than I can get it going and watch the sandbox Blade 100
grind a simple mail for hours :-)


(Mr.) Hannu Liljemark  |  Appelsiini Finland Oy  |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]