Sorry, I meant turning them off for mailboxes. We'll still use it for
deliverdb stuff, because deadlocks there seem to be much less disruptive
and happen less often for some reason. And, of course, it would hurt
performance a lot.
Michael
--On Tuesday, January 15, 2002 20:11:59 -0500 Lawrence Greenfield
<[EMAIL PROTECTED]> 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
> >
> >
>
>
>
>
