"Cheryl L. Southard" wrote: > Does anyone know if the "-m" flag is now more stable? We've since > upgraded to Spamassassin 2.54 and Solaris 9.
I don't recall hearing any bugs specific to -m, but I though I saw some odd behaviour reported on Solaris. > Or maybe you folks can help me find another solution to my e-mail problems. > It seems that every month or so, our e-mail server goes into swapping hell. > Basically it runs out of real memory and starts swapping. We've > already setup limits on our sendmail so that we have a > CONNECTION_RATE_THROTTLE of 3 and a MAX_DAEMON_CHILDREN of 20. MAX_DAEMON_CHILDREN only applies to "internal" sendmail processes and SMTP-connection-related processes (milters, queue runners, inbound mail), but NOT to local deliver processes. :/ Look into setting QUEUE_LA, REFUSE_LA, and BAD_RCPT_THROTTLE. > Normally, > spamd takes about 30 seconds to complete, *blink* That, IMHO, is already far too long. > but when it's in swapping-hell > it takes approximately 550 seconds, and since each one takes 20MB of > memory, quite a few (up to MAX_DAEMON_CHILDREN, I suppose) Up to the limit specified by the -m argument to spamd, if given. > can start up and our > mail server runs out of memory. Usually other things are going on > with the mail server at these times, so it's not entirely spamc/spamd > that is causing the swapping. Things like, oh, say, POP3 and IMAP access, webmail access...? <g> > I see that there is a "-t" flag for spamc, but this doesn't > subsequently kill the spamd processes after the timeout value is > reached. Is there anyway of telling spamd to stop working if we are > swapping a lot? I see that spamd has a lot of little timeout > variables for various specific tests, but is there an overall timeout > for the entire spamd session? This *should* be possible; but without a deep wander through the code I can't tell. spamc/spamd would also need to be modified to allow a proper "failure" code to be returned so that procmail (or whatever called spamc) can recognize this and tempfail or temporarily reject the message. > Another alternative that I can't quite figure out how to impliment is > to setup the procmailrc file to check the memory and only run > spamc/spamd if there is enough. We already use procmail to deliver > local e-mail. Does anyone know a procmailrc rule that we can put in > that can check the amount of swapping that is currently taking place? I don't know about memory checking per se, but I wrote a (very) small program to check the load average (specified on its command line) to tempfail local deliveries if load started to go too high. Some basic knowledge of system calls (and the differences between Linux and Solaris :/ ) should be able to transform it into a memory-load checker. I've posted it at ftp://ftp.deepnet.cx/pub/devel/loadavg. It's currently keeping the PII/450 filter server I'm administering from bogging down too badly during a mail spike. > My current site-wide procmailrc looks like this: > DROPPRIVS=yes > :0fw > | spamc > > Thanks, > > Cheryl > -- > Cheryl Southard > [EMAIL PROTECTED] > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Spamassassin-talk mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/spamassassin-talk -- <erno> hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
