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 13:35:28 -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: <20070518163703.GH29250@marvin.we-be-smart.org>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <464DBC1B.30204@sourcefire.com> <20070518163703.GH29250@marvin.we-be-smart.org>
User-agent: Thunderbird 1.5.0.9 (X11/20070104)
Kyle Wheeler wrote:
On Friday, May 18 at 10:45 AM, quoth Alex Kirk:
Here's the issue: over the past several months, I've had occasional random instances where the box in question will have slowed to a crawl, and when I log in, I see literally dozens of qmail-smtpd processes, each eating as much CPU as they can

Hmm, okay.

* Netqmail-1.05 with the validrcptto patch, and the patch that lets me route all mail across a relay (forget the name of the patch; relaying through outbound.mailhop.org, a DynDNS.com service)

...huh? Validrcptto I get, the other one, though... You can relay all mail through an external server by just using smtproutes. Are you saying you need to authenticate to that remote server? (If so, I have had very little luck with that patch; it is *full* of bugs, and I haven't had the time to find them all.)

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, 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.
@40000000464db27218ab8764 tcpserver: fatal: unable to bind: address already used

Hmmm, that's no good. It looks like you have some rogue tcpserver instances. Make sure your qmail-smtpd run file (/service/qmail-smtpd/run) is correct (you can post it to the list, if you like).

Gladly:

schnarff.com:/home/packages/netqmail-1.05$ cat /service/qmail-smtpd/run
#!/bin/sh

QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
LOCAL=`head -1 /var/qmail/control/me`

if [ -z "$QMAILDUID" -o -z "$NOFILESGID" -o -z "$MAXSMTPD" -o -z "$LOCAL" ]; then
   echo QMAILDUID, NOFILESGID, MAXSMTPD, or LOCAL is unset in
   echo /var/qmail/supervise/qmail-smtpd/run
   exit 1
fi

if [ ! -f /var/qmail/control/rcpthosts ]; then
   echo "No /var/qmail/control/rcpthosts!"
echo "Refusing to start SMTP listener because it'll create an open relay"
   exit 1
fi

exec /usr/local/bin/softlimit -m 2000000 \
/usr/local/bin/tcpserver -v -R -l "$LOCAL" -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /var/qmail/bin/qmail-smtpd 2>&1

What's truly bizzare at this point is that the issue has mostly gone away again. I'm still randomly seeing up to 4 Qmail processes at a time spinning their wheels, but for the most part, they're actually winding back down and dying on their own after a few minutes. This started happening without any changes at all from me.

Meanwhile, I've used qmHandle (http://sourceforge.net/projects/qmhandle) to go clean my local and remote queues, which did have a bunch of old messages in them (some without subjects/ or To/From addresess, others with characters that didn't display properly in my terminal), at the urging of Seth Kurtzberg (who appears to have posted off-list, but thanks anyway). I'm not sure that that's even related, but I figure it doesn't hurt.

Alex Kirk

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