<div dir="ltr">On Wed, Feb 26, 2014 at 12:27 AM, Willy Offermans <span dir="ltr"><<a href="mailto:Willy@offermans.rompen.nl" target="_blank">Willy@offermans.rompen.nl</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Steve and Cyrus friends,<br>
<div><div class="h5"><br>
On Tue, Feb 25, 2014 at 11:03:30AM -0800, Stephen Ingram wrote:<br>
> I'm running a very small murder setup using Simon Matter's RPM packages on<br>
> CentOS 6.x. Frequently, the tis_sessions.db file on the update master<br>
> becomes corrupt such that one or more of the nodes can no longer establish<br>
> a connection. Of course, this results in folders not reserved properly on<br>
> the master and a long list of issues from there. Each time I see the<br>
> behavior in the logs:<br>
><br>
> tlsv1 alert decrypt error in SSL_accept() -> fail<br>
> STARTTLS negotiation failed: imap1.xxx.xxx<br>
> Connection reset by peer, closing connection<br>
><br>
> Stopping cyrus-imapd, removing tls_sessions.db and then restarting<br>
> cyrus-imapd always solves the problem. Is the tls database typically this<br>
> unreliable (can't imagine why as it's the same db used for the mail,<br>
> right?) and perhaps I should just not cache these connections or is there<br>
> something else that could be wrong?<br>
><br>
> Steve<br>
<br>
</div></div>> ----<br>
> Cyrus Home Page: <a href="http://www.cyrusimap.org/" target="_blank">http://www.cyrusimap.org/</a><br>
> List Archives/Info: <a href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/" target="_blank">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a><br>
> To Unsubscribe:<br>
> <a href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus" target="_blank">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a><br>
<br>
How do you know that tls_sessions.db is corrupt?<br>
<br>
Is this really the right order:<br>
<br>
1) tls_sessions.db becomes corrupt<br>
2) > tlsv1 alert decrypt error in SSL_accept() -> fail<br>
<div class=""> > STARTTLS negotiation failed: imap1.xxx.xxx<br>
> Connection reset by peer, closing connection<br>
<br>
</div>To me, the one is independent of the other, meaning that a corrupted<br>
tls_sessions.db is not related to STARTTLS and a STARTTLS negotiation<br>
failed does not necessarily leads to a corrupted tls_sessions.db.<br></blockquote><div><br></div><div>It very well could be; I'm really not sure. However, removing the tls_sessions.db file and restarting Cyrus solves the issue 100% of the time. Simply restarting Cyrus without changing anything does not.</div>
<div><br></div><div>I'm certainly open to other possibilities, but in the absence of anything else, I'm thinking there is something to this. I suppose the next step might be trying to export the db to text format.</div>
<div><br></div><div>Steve</div></div><br></div></div>