Are your users doing any other kind of login/authentication other than via the submission port (587)? If so, I'd try upping the softlimit on the other run files. I only did submission because that's the only port I'm using.
From: Steve Linberg <[email protected]> Reply-To: <[email protected]> Date: Thursday, June 9, 2016 at 12:17 PM To: <[email protected]> Subject: Re: [qmailtoaster] vchkpw segfaults and spamdyke errors 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.
