Mine is at 48000000. I did have to increase it to there. but I am running on QMT-ISO which is somewhat aged although I have kept the qmailtoaster and OS updated and it is 32 bit. I am running in a VM but I do not believe that matters.
I do not think imap uses the submission run file. Should it not use the imap4 run file? Be sure to confirm it is segfaulting on the submission process. FWIW my softlimit for imap4 run is 9000000, and for imap4-ssl is the same. I see several bugs out and about for libc segfaults. Here is one from fedora19: https://bugzilla.redhat.com/show_bug.cgi?id=986427 you might look along those lines, make sure you glibc is not old, etc. are you using a hosts.deny or allow file? Might fall in line with the above then even though it is somewhat old. this does not look like it will be easy to resolve unfortunately. From: Steve Linberg [mailto:[email protected]] Sent: Thursday, June 09, 2016 9:17 AM 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.
