frequently corrupt tis_sessions.db files

[Stephen Ingram]

On Wed, Feb 26, 2014 at 12:27 AM, Willy Offermans <Willy at offermans.rompen.nl
> wrote:

> Dear Steve and Cyrus friends,
>
> On Tue, Feb 25, 2014 at 11:03:30AM -0800, Stephen Ingram wrote:
> > I'm running a very small murder setup using Simon Matter's RPM packages
> on
> > CentOS 6.x. Frequently, the tis_sessions.db file on the update master
> > becomes corrupt such that one or more of the nodes can no longer
> establish
> > a connection. Of course, this results in folders not reserved properly on
> > the master and a long list of issues from there. Each time I see the
> > behavior in the logs:
> >
> > tlsv1 alert decrypt error in SSL_accept() -> fail
> > STARTTLS negotiation failed: imap1.xxx.xxx
> > Connection reset by peer, closing connection
> >
> > Stopping cyrus-imapd, removing tls_sessions.db and then restarting
> > cyrus-imapd always solves the problem. Is the tls database typically this
> > unreliable (can't imagine why as it's the same db used for the mail,
> > right?) and perhaps I should just not cache these connections or is there
> > something else that could be wrong?
> >
> > Steve
>
> > ----
> > Cyrus Home Page: http://www.cyrusimap.org/
> > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> > To Unsubscribe:
> > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>
> How do you know that tls_sessions.db is corrupt?
>
> Is this really the right order:
>
> 1) tls_sessions.db becomes corrupt
> 2) > tlsv1 alert decrypt error in SSL_accept() -> fail
>    > STARTTLS negotiation failed: imap1.xxx.xxx
>    > Connection reset by peer, closing connection
>
> To me, the one is independent of the other, meaning that a corrupted
> tls_sessions.db is not related to STARTTLS and a STARTTLS negotiation
> failed does not necessarily leads to a corrupted tls_sessions.db.
>

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.

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.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20140325/500c32d9/attachment.html