Thanks Martin, that helps let me know I haven't completely lost it.
I downloaded the patches, and am inexperienced in how to use "patch". Tried several things, but assumed to place the patch files in /SpamAssassin-3.0.2 directory, and then ran patch -i<patchfile>, which didn't really work.
Is the patch process difficult to explain, or should I just wait for 3.10?
Thanks!
| Martin Hepworth <[EMAIL PROTECTED]>
01/19/2005 01:02 PM |
|
Leonard
know issue with sa 3.0x and spamc/spamd. Will ne Fixed with 3.10
work around is lower number of children allowed or apply following patches..
http://bugzilla.spamassassin.org/show_bug.cgi?id=3983
--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
[EMAIL PROTECTED] wrote:
>
>
> This is my first post here, and liable to be a doozie!
>
> Running SA 3.0.2 with Sendmail 8.12.11, hooked in with spamass-milter
> 0.2.0, all under Solaris 9. I also have SPF-Milter installed from
> spf.pobox.com. SPF is the first milter, SA is the second
> in the sendmail.cf file.
>
> Sendmail running only as MTA with user delivery responsibilities.
>
> I was able to build and install SA and the milter on a test machine
> (running same config, except Solaris 8). Test machine was loaded with
> gcc 3.3.2.
>
> We are starting SA and the spamass-milter program using the following
> script:
>
> #!/sbin/sh
> #
> # From: [EMAIL PROTECTED] (Scott Griffith, ISES-LLC)
> # To: <[EMAIL PROTECTED]>, <[email protected]>
> # Subject: Re: [Spamassassin-talk] SysV-style startup script
> # Date: Sat, 24 Nov 2001 12:09:16 -0700
> #
> # In case there are any Solaris folks out there who aren't comfortable
> # with their own rc scripts, here's what I've been using for Solaris 7
> # from day 1 with no problems. Filename:
> #
> # /etc/rc2.d/S78spamd
>
> #PATH=$PATH:/usr/bin:/usr/local/bin:/sbin:/bin:/usr/sbin
> PATH=$PATH:/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin
> DAEMON=/usr/local/sbin/spamass-milter
> SOCKET=/var/run/spamass.sock
> DESC="Sendmail milter plugin for SpamAssassin"
>
> case "$1" in
> 'start')
> if [ -x /usr/bin/spamd -o -x /usr/local/bin/spamd ]
> then
> spamd -d -m 20 -u <obscured> --syslog-socket=inet
> --nouser-config
> fi
>
> $DAEMON -p $SOCKET -i 192.168.<obscured> &
>
> ;;
>
> 'stop')
> /usr/bin/pkill -9 -x -u <obscured> '(spamd)'
>
> /usr/bin/pkill -9 -x -u 0 'spamass-milter'
> rm $SOCKET
>
> ;;
>
> *)
> echo "Usage: $0 { start | stop }"
> exit 1
> ;;
> esac
> exit 0
>
> I had good success passing occasional messages through SA to test mail
> accounts and it seems to work just as expected. On the test machine, I
> was able to change
> /etc/mail/spamassassin/local.cf to match our needs and local
> configuration. Our only intent is to let SA tag the X-Spam* headers,
> providing no change to subject or body of the messages.
>
> The problem I am having now is that under a production load (~30,000
> SMTP connections per day), it looks like spamd/spamc handoff is slowing
> to a crawl and consuming great amounts of memory. The first 2-3 emails
> that come in after starting process within 2-5 seconds each, and after
> about 20 messages, the time spamd takes to process gets up into 100+
> seconds. With a steady volume of mail coming in, everything eventually
> chokes down, as sendmail itself starts backing up tremendously.
>
> The only thing that I did "out of the ordinary" was that I compiled
> everything on our test machine, tar'd up the directories that everything
> was built into, untar'd on the production machine, and ran "make
> install". I did it this way because in our situation, compiling on the
> production sendmail machine is frowned upon. This very well could be
> the reason of my slowdown problems, and before I go fight the "but I
> have to be able to compile in production", I wanted to see if anyone had
> any ideas about what could be causing the slowdowns.
>
> I know it's a LONNG first post, and thanks to any/all that can muddle
> through and reply.
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.
**********************************************************************
