How funny...it was because of your README that I found the issue as to why I couldn't log in using my cell phone, but could log in using Outlook. Logging in via my cell phone was causing segfaults with vchkpw (which Steve is dealing with), so I saw your README and tried raising my softlimit, which fixed the problem. I didn't notice until now that you have one more 0 than I do. Mine is at 128000000 and works fine....
From: Eric <[email protected]> Reply-To: <[email protected]> Date: Saturday, June 11, 2016 at 11:33 AM To: <[email protected]> Subject: Re: [qmailtoaster] vchkpw segfaults and spamdyke errors I now remember why I set my submission softlimit high, to 1280000000--again, I never checked on setting it lower. It had to do with one of my user's email client software, eM client. The problem never occurred with Thunderbird of Outlook, only with eM client. I was going through my readme (ftp://ftp.whitehorsetc.com/pub/repo/qmt/CentOS/7/current/x86_64/1.qmail-cen tos7-install.README) and found that I had logged of this problem. On 6/6/2016 11:21 AM, Eric wrote: > Hi Steve, > > My /var/qmail/supervise/submission/run is as follows: > > <run> > #!/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 1280000000 \ > /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 > </run> > > > > Note the difference in our softlimits: > 1280000000 > 160000000 > > Eric > > On 6/6/2016 9:12 AM, Steve Linberg wrote: >> Greetings all. >> >> Overall, my new toaster build is working great; however, combing the >> logs, I still see a couple of issues I’d like to get to the bottom of. >> (CentOS 7.2, built the toaster a couple of weeks ago.) >> >> The first is that I’m still getting a ton of segfaults from vchkpw, even >> having raised the softlimit in /var/qmail/supervise/submission/run from >> the default of 64000000 to 100000000, 128000000 and even 160000000. I >> sometimes have 20 or more in a row in my logs: >> >> Jun 6 08:43:18 xxx kernel: vchkpw[25196]: segfault at 0 ip >> 00007fca89bdbad6 sp 00007ffda62cef98 error 4 in >> libc-2.17.so[7fca89aa9000+1b7000] >> Jun 6 08:43:21 xxx kernel: vchkpw[25200]: segfault at 0 ip >> 00007f2dd9f91ad6 sp 00007ffc754d7b58 error 4 in >> libc-2.17.so[7f2dd9e5f000+1b7000] >> Jun 6 08:43:23 xxx kernel: vchkpw[25204]: segfault at 0 ip >> 00007feb85bf8ad6 sp 00007ffe1ad395c8 error 4 in >> libc-2.17.so[7feb85ac6000+1b7000] >> >> That said, I’m able to send / receive mail and log in to my imap system >> without any problems, so I suspect these are triggered by login attempts >> from someone else, but segfaults aren’t something I’m used to being >> comfortable with, and I’m not even sure where to begin troubleshooting >> this. Googling this hasn’t gotten me far. It may be a CentOS issue and >> not a toaster issue, but it’s still a bit unnerving. Is there anything >> else in the toaster config that I can look at or that might cause this? >> >> The second is hundreds of error messages from spamdyke in >> /var/log/maillog: >> >> Jun 6 10:56:32 xxx spamdyke[30667]: ERROR: invalid/unparsable >> nameserver found: 2001:4860:4860::8844 >> Jun 6 10:56:32 xxx spamdyke[30667]: ERROR: invalid/unparsable >> nameserver found: 2001:4860:4860::8888 >> >> These are constant, and always with those addresses, which I’m 99% sure >> are Google’s DNS servers in ipv6. I’m not actively using ipv6, and my >> first thought was to just turn it off (in /etc/sysctl.conf), but even >> after a reboot, I was still getting these messages, over and over in >> /var/log/maillog. >> >> Does anybody have any ideas on either of these issues? Thanks in advance. >> >> -- >> Steve Linberg, Chief Goblin >> Silicon Goblin Technologies >> http://silicongoblin.com >> Be kind. Remember, everyone you meet is fighting a hard battle. >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
