Are the database locking gremlins (referred to below) the same issue as the
locking lmtp problem that I and many others posted to the list about?
Did I miss something, or does using a flat file for the database rectify the
problem where users cannot move or delete messages until the Imap PID for that
user is killed?
-John
Lawrence Greenfield wrote:
> The database deadlocking gremlins usually cause an lmtpd or imapd
> process to crash while holding a database lock. The number one thing
> is to find out which process crashed, why it crashed, and to stop it.
>
> The master should syslog whenever a process exiting abnormally
> ("grep signal /var/log/cyrus.log").
>
> We're using Berkeley db 3.1.17 on Solaris 2.7 and haven't had any
> problems since upgrading to Cyrus 2.1, though we use a flat text
> mailboxes file. (But there's still the deliverdb/tls database).
>
> Michael, when you say you're going to compile a all cyrusdb_flat,
> which version are you talking about? Making deliverdb use a flat text
> file would really hurt performance.
>
> To get things straight, by default:
>
> Cyrus 2.0.16 uses Berkeley db w/ txns for mailboxes.
> It uses Berkeley db w/o txns for deliverdb (and has for a long time).
> It uses flat text files for storing seen state.
>
> Cyrus 2.1 uses Berkeley db w/ txns for mailboxes.
> It uses Berkeley db w/ txns for deliverdb.
> It uses flat text files for storing seen state.
> It uses Berkeley db w/ txns for storing TLS session information.
>
> We run Cyrus 2.1 with:
> flat mailboxes
> db3_nosync deliverdb
> flat seen state
> db3_nosync TLS
>
> I'm working on another reliable non-Sleepycat format for the mailboxes
> file since it's become apparent that no large volume site can use
> Sleepycat. I don't see any reasonable alternatives for deliverdb or
> TLS information right now.
>
> Larry
>
> Date: Tue, 15 Jan 2002 16:32:01 -0500
> From: Michael Bacon <[EMAIL PROTECTED]>
>
> You've apparently made the aquaintance of the database deadlocking
> gremlins. We've been running into this one since upgrading to 2.0.16, and
> have yet to find a good solution for it. Because we've finally gotten sick
> of them, we're about to install a version of cyrus that was recompiled
> using all cyrusdb_flat instead of cyrusdb_db3 to see if it helps. In the
> meantime, you can probably cut down on the frequency of the errors by
> setting prefork=0. I don't know why, but the preforks seem to make the
> problem happen more frequently.
>
> Michael Bacon
> Duke University
> [EMAIL PROTECTED]
>
> --On Tuesday, January 15, 2002 15:52:59 -0500 Chris Peck <[EMAIL PROTECTED]>
> wrote:
>
> > Yesterday I started to see (for the first time since upgrading to
> > cyrus-2.0.16 on Jan 4th) a lot of messages from sendmail which indicated:
> > "Could not connect to socket /var/imap/socket/lmtp: Connection refused by
> > localhost". I checked and there were no lmtpd processes running, even
> > though my cyrus.conf indicated a prefork=1 for them. This, of course,
> > really messes up our mail delivery, since mail is coming in, but, it's
> > not getting delivered. I stopped sendmail & cyrus master, then started
> > cyrus master & sendmail & it started up fine. About 4 hours later, the
> > same thing happened. Once again I went through the restart process. I
> > then rebooted our system around 6:00 pm last night (students return
> > today), and all was fine until around 1:30 this afternoon, when I started
> > getting the same messages in syslog, but, there were about 30 lmtpd's
> > running (over 100 sendmail's). This time I waited & after a few minutes
> > lmtp would accept the connects, then reject them, etc. Finally, I went
> > through the restart process & it has been running fine since.
> >
> > Needless to say, I am very concerned about this. It sounds like I'm
> > running into a resource problem, but, I have checked swap, disk space,
> > memory usage, etc, and all seems fine. Is it possible that I need to
> > increase a network resource? Or maybe, tell master to increase his
> > listen queue on startup?
> >
> > Here's the cyrus.conf file:
> >#
> ># cyrus.conf
> >#
> ># taken from prefork.conf as distributed with cyrus
> ># 20011010 - initial create date <crpeck>
> >#
> >
> > START {
> > # do not delete these entries!
> > mboxlist cmd="ctl_mboxlist -r"
> > deliver cmd="ctl_deliver -r"
> >
> > # this is only necessary if using idled for IMAP IDLE
> > # idled cmd="idled"
> > }
> >
> ># UNIX sockets start with a slash and are put into /var/imap/sockets
> > SERVICES {
> > # add or remove based on preferences
> > imap cmd="imapd" listen="imap" prefork=5
> > imaps cmd="imapd -s" listen="imaps" prefork=1
> > pop3 cmd="pop3d" listen="pop3" prefork=5
> > pop3s cmd="pop3d -s" listen="pop3s" prefork=1
> > sieve cmd="timsieved" listen="sieve" prefork=0
> >
> > # at least one LMTP is required for delivery
> ># lmtp cmd="lmtpd" listen="lmtp" prefork=0
> > lmtpunix cmd="lmtpd" listen="/var/imap/socket/lmtp" prefork=1
> > }
> >
> > EVENTS {
> > # this is required
> > checkpoint cmd="ctl_mboxlist -c" period=30
> >
> > # this is only necessary if using duplicate delivery suppression
> > delprune cmd="ctl_deliver -E 3" period=1440
> > }
> >
> > Any suggesations on where to start would be appreciated...
> >
> > -thanks
> > chris
> >
> >
> > Chris Peck
> > Manager of Unix Services
> > Information Technology
> > The College of William and Mary
> > Williamsburg, VA 23187
