I’ve been incrementally raising the softlimit in
/var/qmail/supervise/submission/run over the past few days in an effort to stop
the vchkpw segfaults, and I’ve taken it all the way up to 1200000000:
#!/bin/sh
QMAILDUID=`id -u vpopmail`
NOFILESGID=`id -g vpopmail`
MAXSMTPD=`cat /var/qmail/control/concurrencyincoming`
SMTPD="/var/qmail/bin/qmail-smtpd"
TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb"
HOSTNAME=`hostname`
VCHKPW="/home/vpopmail/bin/vchkpw"
export REQUIRE_AUTH=1
exec /usr/bin/softlimit -m 1200000000 \
/usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 587 \
$SMTPD $VCHKPW /bin/true 2>&1
Unfortunately, it doesn’t seem to have made any difference at all in the number
or frequency of segfaults.
Jun 9 11:56:44 xxx kernel: vchkpw[29989]: segfault at 0 ip 00007f687b728ad6 sp
00007ffc7d038908 error 4 in libc-2.17.so[7f687b5f6000+1b7000]
I just can’t believe that 1.2 BILLION BYTES isn’t enough to handle qmail-smtp
or an imap login or whatever it’s doing here. My previous qmailtoaster build
runs on a VM with 512mb total RAM, also running Apache and Mailman, and has
never segfaulted. There must be something else going on.
Is “qmailctl restart” the right way to activate changes to
/var/qmail/supervise/submission/run? That’s what I’ve been doing.
Anybody have any other ideas or theories? Again, this is a clean CentOS 7.2 VM
at DigitalOcean, with 2gb RAM. I’ve disabled ipv6 and selinux.
--
Steve Linberg, Chief Goblin
Silicon Goblin Technologies
http://silicongoblin.com
Be kind. Remember, everyone you meet is fighting a hard battle.
