Qmail
[Top] [All Lists]

Re: Dozens of qmail-smtpd processes eating 100% of CPU

To: qmail@list.cr.yp.to
Subject: Re: Dozens of qmail-smtpd processes eating 100% of CPU
From: Alex Kirk <alex.kirk@sourcefire.com>
Date: Fri, 18 May 2007 15:09:27 -0400
Delivered-to: sp-com-lists@consult.net
Delivered-to: gmail-qmail@securepoint.com
Delivered-to: sp.com.list@gmail.com
Delivered-to: mailing list qmail@list.cr.yp.to
In-reply-to: <20070518175145.GA18422@caesar.cse.nd.edu>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <464DBC1B.30204@sourcefire.com> <20070518163703.GH29250@marvin.we-be-smart.org> <464DE3E0.8070200@sourcefire.com> <20070518175145.GA18422@caesar.cse.nd.edu>
User-agent: Thunderbird 1.5.0.9 (X11/20070104)

Are you *sure* you aren't using any other patches? For example, if you're using the SSL patch, this can happen if something goes wrong with the dk512.pem and dh1024.pem files. http://forum.swsoft.com/showthread.php?s=2add0886d6e03c00621b94bf45a80858&threadid=40173

I suspect we're going to need to know *exactly* what patches you're using in order to debug it.
Valid point. I know I've got the TLS patch enabled

Ahh, then I think we have a likely candidate for official culprit here! Check those .pem files (do they exist, do they have the right names, do they have the right permissions); I'm guessing that something is wrong with them.

What happens is that when someone tries to send mail to your server and requests SSL encryption (e.g. via STARTTLS), if those files aren't there, the SSL-patched qmail-smtpd will generate the data it expected to find in those files. Doing that generating can take a while (and a lot of CPU). Create those files and update them regularly (per the documentation that comes with the SSL patch), and it'll be *much* faster.

Here's my question: I have /var/qmail/control/clientcert.pem and /var/qmail/control/servercert.pem, but not dk512.pem and dh1024.pem. In fact, I'd never seen those two file names previous to today. Are you absolutely certain that I need files with those names, or would the ones I have work?
and I am authenticating to my relay server. To be honest, I forget exactly which patch I used for that...I got it working very late at night after several hours of poking at it and trying different patches, and I was so confused by the time I finished I just threw my hands up and said "thank goodness it works!" Looks like I have a "qmail-remote-auth.patch" in my Qmail source directory, so that's probably it.

Mmm... yich. Well, if it works for you, cool. (It liked breaking on me.) It's probably got a few dozen little bugs in there, and possibly a security flaw or two---so if you have the time, I highly recommend looking into fixing it.

::Sigh:: I'll put it on my list. I'd love to fix it -- it's a horribly buggy patch -- but it may be a while before I find the time. Of course, if anyone reading this wants to pay me to fix it (the work would still be GPL/BSD/whatever open license it currently is), I'll prioritize it. ;-)

On 5/18/07, Kyle Wheeler <kyle-qmail@memoryhole.net> wrote:
Well, if I'm right and it is the TLS/SSL patch, then it will only
become a problem when people who support STARTTLS attempt to contact
you. Since many servers do not, it won't be a problem most of the
time.

This one's pretty easy to check too..  Set your mail client up to use
TLS and start sending mail..  Watch the processor and if you see it
spike when you start trying to send, this could very well be the
problem.

No such luck. I've already had the mail client I'm using now configured to use TLS, so I turned on top and sent a message to the misbehaving server. No rogue processes at all -- I didn't even see a new qmail-smtpd before the message was delivered. So I'm pretty sure it's not just a STARTTLS thing.

Alex

<Prev in Thread] Current Thread [Next in Thread>