On Wed, 03 Dec 2003, Rob Siemborski wrote:
> On Wed, 3 Dec 2003, Christian Schulte wrote:
> > Richard Gilbert schrieb:
> > > The reason why I am restarting the server is to deal with the odd
> > > "IOERROR: reading message: unexpected end of file" errors, which I am
> > > still getting, which first
On Wed, 3 Dec 2003, Christian Schulte wrote:
> Richard Gilbert schrieb:
> > The reason why I am restarting the server is to deal with the odd
> > "IOERROR: reading message: unexpected end of file" errors, which I am
> > still getting, which first led me to the lock_flock patch (archive message
> >
Richard Gilbert schrieb:
The reason why I am restarting the server is to deal with the odd
"IOERROR: reading message: unexpected end of file" errors, which I am
still getting, which first led me to the lock_flock patch (archive message
18705).
This is interesting. I am also seeing these entries fro
at the system was unavailable until
> > about 08:39 because of database recovery.
> >
> > Nov 19 05:00:11 impala master[9697]: [...] process started
> > Nov 19 05:00:11 impala ctl_cyrusdb[9698]: [...] recovering cyrus databases
> > Nov 19 05:05:10 impala ctl_mboxlist[10854
On Thu, 20 Nov 2003, Henrique de Moraes Holschuh wrote:
> IMHO all that pid tracking code should be added to 2.1 as well.
2.1 is going to be basically end-of-life (barring currently unforseen
issues) when I release 2.1.16 later today... and as such we've been trying
to avoid significant code chan
d to find that the system was unavailable until
> > about 08:39 because of database recovery.
> >
> > My question is: was this database recovery caused by the system realising
> > that the software had changed, or was it a complete coincidence? We
> > restart the system three ti
On Thu, 20 Nov 2003, Philipp Sacha wrote:
> I could reproduce stucking behaviour of lmtp by starting cyrus with 5
> preforked "lmtpd -a" processes. When i kill that processes manually
> and then try to telnet to port lmtp on the mailserver, i have a stuck
> lmptd. That means that port lmtp is op
One with deadlock problems and thinking of using the flock patch should
read the stuff in https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1177
The POSIX alarm fix for the timeout/deadlocks stuff is working just fine
here. Unfortunately Philipp Sacha didn't reply yet to give us a second
testimony
I was surprised to find that the system was unavailable until
> about 08:39 because of database recovery.
>
> Nov 19 05:00:11 impala master[9697]: [...] process started
> Nov 19 05:00:11 impala ctl_cyrusdb[9698]: [...] recovering cyrus databases
> Nov 19 05:05:10 impala ctl
about 08:39 because of database recovery.
Nov 19 05:00:11 impala master[9697]: [...] process started
Nov 19 05:00:11 impala ctl_cyrusdb[9698]: [...] recovering cyrus databases
Nov 19 05:05:10 impala ctl_mboxlist[10854]: [...] skiplist: recovered
/var/imap/mailboxes.db (61786 records, 4909724
On Wed, 10 Sep 2003, Scott Adkins wrote:
> So, you guys seeing around a 20MB virtual size and a 1MB resident size
> when looking at the process table, right?
Yes. There is also 5-6MB shared 'resident' size (libs, etc).
>
> Scott
>
> --On Wednesday, September 10, 2003 11:09 AM -0400 Rob Siembor
So, you guys seeing around a 20MB virtual size and a 1MB resident size
when looking at the process table, right?
Scott
--On Wednesday, September 10, 2003 11:09 AM -0400 Rob Siemborski
<[EMAIL PROTECTED]> wrote:
On Wed, 10 Sep 2003, Igor Brezac wrote:
My installation of cyrus 2.2-CVS on Solaris
On Wed, 10 Sep 2003 10:48:34 -0400 (EDT)
Igor Brezac <[EMAIL PROTECTED]> wrote:
> My installation of cyrus 2.2-CVS on Solaris 9 shows the same memory
> footprint per process. 20M is taken by mmap(), the rest is shared
> physical memory and about 1M of 'private' physical memory per process
> (imap
On Wed, 10 Sep 2003, Scott Adkins wrote:
> So, you guys seeing around a 20MB virtual size and a 1MB resident size
> when looking at the process table, right?
Yes.
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 *
On Wed, 10 Sep 2003, Igor Brezac wrote:
> My installation of cyrus 2.2-CVS on Solaris 9 shows the same memory
> footprint per process. 20M is taken by mmap(), the rest is shared
> physical memory and about 1M of 'private' physical memory per process
> (imapd, pop3d, lmtpd, etc).
This is consista
On Wed, 10 Sep 2003, Scott Adkins wrote:
> Well, I am not sure that it is something bizarre going on with the mmap()
> method that configure chose at compile time. I still have to do some
> testing, but I am not really convinced that the 27MB/28MB sizes are tied
> in to mailboxes.db being nearly
On Wed, 10 Sep 2003, Scott Adkins wrote:
> Well, I am not sure that it is something bizarre going on with the mmap()
> method that configure chose at compile time. I still have to do some
> testing, but I am not really convinced that the 27MB/28MB sizes are tied
> in to mailboxes.db being nearly
Well, I am not sure that it is something bizarre going on with the mmap()
method that configure chose at compile time. I still have to do some
testing, but I am not really convinced that the 27MB/28MB sizes are tied
in to mailboxes.db being nearly the same size.
So, what kind of things would cause
On Wed, 10 Sep 2003, Scott Adkins wrote:
> So, with 3000+ cyrus process averaging about 20MB each, it consumed pretty
> much all our real RAM (we have 8GB on each cluster member). I would say
> about 6GB of memory was consumed in just Cyrus processes.
This sounds like something bizarre is going
We are running a Tru64 TruCluster system. We have 2 members in the cluster
and run Cyrus IMAP 2.2.1b. We typically ran the system with Cyrus being
CAA'd and only running on one member at a time. The stuff would relocate
to the other cluster member if for some reason it could not run on the first
Hi,
assuming following configuration:
(linux) cluster with two nodes and shared scsi
db3 as database backends
Will cyrus be able to recover databases on failover and get a
consistent state?
Does cyrus recover the databases automatically or do you need to do
manual recovery? The
3 09:01:27 mail imapd[1362]: DBERROR: error exiting application:
DB_RUNRECOVERY: Fatal error, run database recovery
ctl_mboxlist -r, which should be run automatically when the master
process starts up. "recovery" is a Berkeley db term for resetting the
database and it's environment
okay, reconstruct -m gives:
%/usr/cyrus/bin/reconstruct -m
reconstructing mailboxes.db currently not supported
so how does one recover from the below message?
Nov 3 09:01:27 mail imapd[1362]: DBERROR: error exiting application: DB_RUNRECOVERY:
Fatal error, run database recovery
Thanks
23 matches
Mail list logo
