-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
use GNU patch (std answer to any Solaris question ;). use "patch -p0". step 5 should be unnecessary, and in its place, be sure to run "make clean". - --j. Martin Hepworth writes: > Leonard > > most odd - perhaps ask the people involved in that bug (ie create an > bugzilla acct and ask then how to debug so you can get the thing going). > > There is a flag on the spamd startup that limits the number it will > span which achieves a similar effect to the patch,, > > -m num, --max-children=num Allow maximum num children > --max-conn-per-child=num Maximum connections accepted > by child > > try adjusting these and see if it works better using the standard 3.02 > distribution. > > -- > Martin Hepworth > Snr Systems Administrator > Solid State Logic > Tel: +44 (0)1865 842300 > > [EMAIL PROTECTED] wrote: > > > > Martin, > > > > I'm having a little problem with the patch, as I'm admittedly not > > extremely "perl savvy". Perhaps you can see what I might be doing wrong > > and steer me in the right direction. > > > > 1. Saving both patches as text files (named patch1 and patch2 > > respectively) into the /Mail-SpamAssassin-3.0.1 directory (I've tried > > with /Mail-SpamAssassin-3.0.2 as well) > > > > 2. Change to the /Mail-SpamAssassin-3.0.1 directory > > > > 3. Run "patch < patch1" > > > > At this point, MANIFEST is updated correctly, but the files that > > SHOULD be created in lib/Mail/SpamAssassin (SpamdForkScaling.pm and > > SubProcBackChannel.pm) are created in the base directory that I'm > > running patch from. > > Also, when patch tries to apply to spamd/spamd.raw it stops saying > > it can't find the file, and I have to manually enter "spamd/spamd.raw" > > to get that patch to apply. > > > > 4. Run "patch < patch2" (this one works fine) > > > > 5. Since SpamdForkScaling.pm and SubProcBackChannel.pm are not in the > > proper directory, I manually copy those to lib/Mail/SpamAssassin > > > > 6. Run "make" followed by "make install". Once again, the > > SpamdForkScaling.pm and SubProcBackChannel.pm are not copied to the > > /usr/local/lib/perl5/site_perl/5.8.3/Mail/SpamAssassin directory, so I > > copy them manually > > > > 7. Start everything up using an rc script > > > > The /var/log/syslog output shows a couple of child processes starting > > up, then shows "prefork: select timeout failed! recovering". Anytime a > > piece of mail is sent through from this point on, the select timeout > > failed message repeats hundreds of times. > > > > FWIW, this is on a Solaris 8 system. > > > > Thanks in advance for any help you could provide. > > > > > > > > *Martin Hepworth <[EMAIL PROTECTED]>* > > > > 01/19/2005 01:02 PM > > > > > > To > > [EMAIL PROTECTED] > > cc > > [email protected] > > Subject > > Re: New to SA, problems with production speed > > > > > > > > > > > > > > > > > > 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?id983 > > > > > > -- > > 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. > > > > ********************************************************************** > > > > > > ********************************************************************** > > 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. > > ********************************************************************** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFCAnHCMJF5cimLx9ARAvWaAKCLq9NuMB6Y8CTxgyCN1RV2qlTkSACgqvU6 jmR86Xhz9f5VYv4Liidmbgk= =vZ0N -----END PGP SIGNATURE-----
