Hi Sam, Turns out the idle timeout didn't help - I've just checked today and there's four spamdyke processes on this one box (haven't checked the others) at 100% utilisation.
Looking at one of the logs, I can again see that it is definitely a spammer. They're specifying multiple RCPT TOs, and Qmail is rejecting a few. The last line of the log is " searching sender blacklist(s); sender...", yet I can see above for other recipients, the line that follows should be "checking relaying; relay-level: 3 recipient:..." Because the full log does contain a bunch of personal addresses and IP addresses, I'll send that to you directly. OS is Debian Lenny on these boxes. Not using softlimit at the moment, and can't seem to find any errors in the Qmail logs that would help things along. Regards, Chris Boulton Lead Engineer BigCommerce / Interspire Email: [email protected] Phone: +61 2 8003 4113 Web: http://www.bigcommerce.com Web: http://www.interspire.com On Sat, Aug 20, 2011 at 1:58 AM, Sam Clippinger <[email protected]> wrote: > I'd be very interested to know how this turns out. Two things bug me about > this solution: no matter what the timeout is, spamdyke should just sit > quietly and wait for more input (using select()); it shouldn't consume any > CPU at all. Also, when the idle timeout is zero and spamdyke disconnects > qmail, then continues the SMTP conversation on its own, it should reset its > idle timeout to 20 minutes to imitate qmail's behavior. > > Of course, if spamdyke is spinning rapidly through its waiting-for-input > loop, strace should show lots of activity. In fact, I don't understand how > a process can consume 100% CPU without showing any activity in strace -- > this makes me distrust the strace output in this case. > > If you could send me a full log file that triggers this behavior, I would > really like to reproduce it. What OS are you running? And have you tried > increasing your "softlimit" value in your "run" file? > > -- Sam Clippinger > > On Aug 18, 2011, at 6:54 PM, Chris Boulton wrote: > > I think I've completely overlooked us not having an idle time-out. > > Turning the logging on, I noticed that the processes were getting stuck > were definitely spammers. I'd say the issue is is exactly how Sam describes > it on the website: > > "Most spam software is pretty stupid and doesn't handle error codes from > SMTP servers. Instead, they send their commands and wait for specific > responses. When those responses don't come, the software just sits forever > and waits" > > I've added timeout values in on a few servers, and we'll see how we go over > the next 24 hours. > > Chris > > > On Fri, Aug 19, 2011 at 12:01 AM, Eric Shubert <[email protected]> wrote: > >> Is it spamdyke that's using the CPU, or another process? clamav had a >> problem doing this sort of thing a couple versions back (0.95.x iirc). >> >> Other than that, I haven't heard of anything like this. I'd look at >> processes related to queuing (scanners?) and see if there's a problem in >> that area. Given your volume, I'd suspect that there's a resource >> constraint that a little configuration tweaking might remedy. >> >> -- >> -Eric 'shubes' >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > > > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > >
_______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
