<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hmmmm.. if that’s the case could you be hitting the the maximum number of accepts??
<div class=""><br class="">
</div>
<div class="">Check the 11.11.1.2. kern.ipc.soacceptqueue section of the FreeBSD handbook</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html" class="">https://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html</a></div>
<div class=""><br class="">
</div>
<div class="">Given the load you described perhaps 128 is just not enough?</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Oct 24, 2016, at 1:22 PM, Eric Cunningham via Info-cyrus <<a href="mailto:info-cyrus@lists.andrew.cmu.edu" class="">info-cyrus@lists.andrew.cmu.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class=""><br class="">
<br class="">
=============================================================<br class="">
Eric Cunningham<br class="">
Information Services - <a href="http://whoi-it.whoi.edu" class="">http://whoi-it.whoi.edu</a><br class="">
Woods Hole Oceanographic Institution - <a href="http://www.whoi.edu" class="">http://www.whoi.edu</a><br class="">
Woods Hole, MA 02543-1541 phone: (508) 289-2224<br class="">
fax: (508) 457-2174 e-mail: <a href="mailto:ecunningham@whoi.edu" class="">
ecunningham@whoi.edu</a><br class="">
=============================================================<br class="">
<br class="">
On 10/24/2016 03:45 PM, Bron Gondwana via Info-cyrus wrote:<br class="">
<blockquote type="cite" class="">On Tue, 25 Oct 2016, at 02:45, Eric Cunningham via Info-cyrus wrote:<br class="">
<blockquote type="cite" class="">Hi list, we're running cyrus imap 2.5.9 built from the FreeBSD 10-2<br class="">
(release-p7) ports tree.<br class="">
<br class="">
The cyrus master process is failing periodically (every 1-2 weeks) as<br class="">
follows:<br class="">
<br class="">
Oct 22 07:38:48 imap1 master[7767]: process type:SERVICE name:imaps<br class="">
path:/usr/local/cyrus/bin/imapd age:305.215s pid:32760 exited, status 71<br class="">
Oct 22 07:38:48 imap1 master[7767]: service imaps/ipv4 pid 32760 in<br class="">
READY state: terminated abnormally<br class="">
Oct 22 07:38:48 imap1 master[7767]: too many failures for service<br class="">
imaps/ipv4, disabling until next SIGHUP<br class="">
<br class="">
This prevents new connections by clients until cyrus is restarted. I've<br class="">
looked around the web but have not seen this issue reported.<br class="">
<br class="">
A little background:<br class="">
<br class="">
Our initial thought on this was that we were running out of listen<br class="">
queues so have upped that incrementally from the default of 32 to a<br class="">
current setting of 32768 via /usr/local/etc/rc.d/imapd using the -l<br class="">
option, with increased kern.ipc.soacceptqueue set to 32768, but that<br class="">
hasn't helped. Sometimes the "status 71" occurs during periods of light<br class="">
use during off hours, like on Saturday mornings.<br class="">
<br class="">
We have ~1400 imap accounts, though the number of impad processes hovers<br class="">
around 3,000-4,000. There have been spikes observed as high as 12,000<br class="">
imapd processes. In that particular case, 1 user had 2 imap clients<br class="">
accounting for near 6,000 of those connections. We've attempted to<br class="">
limit these high numbers using the following imapd.conf values:<br class="">
<br class="">
maxlogins_per_host: 50<br class="">
maxlogins_per_user: 30<br class="">
tcp_keepalive: 1<br class="">
tcp_keepalive_cnt: 1<br class="">
tcp_keepalive_idle: 30<br class="">
tcp_keepalive_intvl: 900<br class="">
<br class="">
However, it seems that once these were reached, no new connections were<br class="">
permitted and resulted in all manner of user complaints about not being<br class="">
able to get at their email.<br class="">
<br class="">
Any ideas on this "status 71" issue? Could an upgrade to 2.5.10<br class="">
possibly address this? Thanks!<br class="">
</blockquote>
<br class="">
<a href="https://www.freebsd.org/cgi/man.cgi?query=sysexits" class="">https://www.freebsd.org/cgi/man.cgi?query=sysexits</a><br class="">
<br class="">
EX_OSERR (71) An operating system error has been detected. This<br class="">
is intended to be used for such things as ``cannot<br class="">
fork'', ``cannot create pipe'', or the like. It<br class="">
includes things like getuid returning a user that<br class="">
does not exist in the passwd file.<br class="">
<br class="">
So the question is: what failed? Is there anything earlier in the log to suggest<br class="">
what the imapd was doing when it died?<br class="">
<br class="">
Bron.<br class="">
<br class="">
</blockquote>
<br class="">
Using the example I posted, I traced back imaps process id 32760 and found only this:<br class="">
<br class="">
Oct 22 07:38:48 imap1 imaps[32760]: accept failed: Software caused connection abort<br class="">
<br class="">
-Eric<br class="">
<br class="">
----<br class="">
Cyrus Home Page: <a href="http://www.cyrusimap.org/" class="">http://www.cyrusimap.org/</a><br class="">
List Archives/Info: <a href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/" class="">
http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a><br class="">
To Unsubscribe:<br class="">
<a href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus" class="">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>