Been a while but we just used to delete deliver.db when it went bad and just
let Cyrus recreate it.
On December 6, 2014 1:07:06 PM AST, Vincent Fox wrote:
>Hi,
>
>We are running quite old Cyrus 2.3.8 (near retirement) and last couple
>of nights it started kicking up this error du
On Sat, 6 Dec 2014, Vincent Fox wrote:
> Hi,
>
> We are running quite old Cyrus 2.3.8 (near retirement) and last couple
> of nights it started kicking up this error during nightly expire run.
>
> cyr_expire[3409]: [ID 386572 local6.error] db
> /var/cyrus/imap/deliver
Hi,
We are running quite old Cyrus 2.3.8 (near retirement) and last couple
of nights it started kicking up this error during nightly expire run.
cyr_expire[3409]: [ID 386572 local6.error] db
/var/cyrus/imap/deliver.db, inconsistent pre-checkpoint, bailing out
Any guidance on best course of
Ok. thx for the aid.
I`m waiting is the last questión over deliver.db, and sorry for my poor
english. When finish the cyr_expire command, how has long the file size?
I suppose the size of the file is delimited by the flag -E.
If the -E flags is the number of day recording, then the size file is
On Mon, 2011-09-12 at 12:40 +0200, Manuel Vazquez wrote:
> Thx for the information. This solution is similar to: ctl_deliver -d >
> flat_text_file?
Sure, ctl_deliver is just a command specifically for the delivery
database.
> Is not possible do query with other tools?
Depends on the format of t
ays. But this deleted the file stored to delete in the trash of mailbox?
>
> Thx for all the aid.
>
> 2011/9/12 Adam Tauno Williams
>
>> On Mon, 2011-09-12 at 12:09 +0200, Manuel Vazquez wrote:
>> > Thx for aid me to solved my question. But i am need query the
>> &
azquez wrote:
> > Thx for aid me to solved my question. But i am need query the
> > information stored in the deliver.db. How do this? With cyradm? O
> > exists other tool more for query the information saved in deliver.db?
>
> You can convert the database to a text file with
On Mon, 2011-09-12 at 12:09 +0200, Manuel Vazquez wrote:
> Thx for aid me to solved my question. But i am need query the
> information stored in the deliver.db. How do this? With cyradm? O
> exists other tool more for query the information saved in deliver.db?
You can convert the data
Thx for aid me to solved my question. But i am need query the information
stored in the deliver.db. How do this? With cyradm? O exists other tool more
for query the information saved in deliver.db?
Thanks for your aid.
2011/9/11 Bron Gondwana
> On Sun, Sep 11, 2011 at 01:34:12PM +0200, Man
On Sun, Sep 11, 2011 at 01:34:12PM +0200, Manuel Vazquez wrote:
> Hi, i'm newbie in the cyrus world. I am admin junior of 1 system of
> corporate mail. In 1 instance of de cyrus imapd i detect the deliver.db file
> have to big size (more de 5GB). I two question over this file.
>
Manuel,
If I'm not mistaken, "deliver.db" is used exclusively for duplicate
message suppression. I can't imagine why it has grown so big (unless
you are not running "ctl_deliver -E" regularly -- normally this is
configured to run every 24 hours or so in /etc/c
Hi, i'm newbie in the cyrus world. I am admin junior of 1 system of
corporate mail. In 1 instance of de cyrus imapd i detect the deliver.db file
have to big size (more de 5GB). I two question over this file.
1. This file have the traffic info of mailbox user?
2. I'm problem with the sp
c in cyr_expire back in 2.3.x.
As far as I understood the man page (and you are right, it's a bit
confusing) - if a mailbox is expired in 5 days, using no '-a' will
result in keeping at least five days history in deliver.db for that
mailbox.
__
Alexei Shilin
--
http://www.fastmail.fm - Same, same, but different...
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
On Tue, May 10, 2011 at 09:11:54PM -0700, Alexei Shilin wrote:
(I see you're one of our customers)
> One of our scanner produces non-unique message-ids when sending mails.
> Ids are repeated in about a week.
I'm guessing this isn't fixable in the scanner - but an alternative
might be to strip i
> Hi,
>
> One of our scanner produces non-unique message-ids when sending mails.
> Ids are repeated in about a week.
>
> So I decided to have deliver.db purged at least once a day, because I
> have duplicatesuppression on in imapd.conf
>
> cyrus.conf
> EV
Hi,
One of our scanner produces non-unique message-ids when sending mails.
Ids are repeated in about a week.
So I decided to have deliver.db purged at least once a day, because I
have duplicatesuppression on in imapd.conf
cyrus.conf
EVENTS {
checkpointcmd="ctl_cyrusdb -c"
VM.
>>>
> The question is what they call "doing maintenance and reboot" :)
>
Quite - I gather it was a memory/disk upgrade on the host
>
>>
>>> {snip}
>> ctl_cyrusdb[3150]: checkpointing cyrus databases
>>> lmtpunix[3155]: DBERROR db4: /var
nd reboot" :)
>>
>> Errors like this appeared in /var/log/maillog after startup.
>>
>>
>
>> {snip}
>>
>
>> ctl_cyrusdb[3150]: checkpointing cyrus databases
>> lmtpunix[3155]: DBERROR db4: /var/lib/imap/deliver.db: unexpected file
>>
> {snip}
>
> ctl_cyrusdb[3150]: checkpointing cyrus databases
> lmtpunix[3155]: DBERROR db4: /var/lib/imap/deliver.db: unexpected file
> type or format
> ctl_cyrusdb[3150]: DBERROR: error listing log files: DB_NOTFOUND: No
> matching key/data pair found
>
>
{snip}
bases
master[3148]: about to exec /usr/lib/cyrus-imapd/idled
{snipped the imap & pop startup messages}
ctl_cyrusdb[3150]: checkpointing cyrus databases
lmtpunix[3155]: DBERROR db4: /var/lib/imap/deliver.db: unexpected file
type or format
ctl_cyrusdb[3150]: DBERROR: error listing log files: DB_NOT
On 15/11/2010 14:46, Patrick Boutilier wrote:
> On 11/15/2010 10:36 AM, David Mayo wrote:
>>
>> Having looked at the source code, we can see that ctl_cyrusdb does not
>> touch deliver.db and it is not possible to force checkpoints on or off
>> within lmtpd. Idea
duplicate deliveries database but this is the only
>> maintenance we can schedule on this database.
>
>
> No solution, but I wonder why your checkpoint takes so long? With
> similar DB size it take only seconds here.
>
>
>
> Nov 8 21:18:04 student2 lmtpunix[6541]: sk
server
was busy in the backed-up delivery process.
Having looked at the source code, we can see that ctl_cyrusdb does not
touch deliver.db and it is not possible to force checkpoints on or off
within lmtpd. Ideally we want to schedule the checkpointing to a "less
sociable" time.
On our s
elivery process.
Having looked at the source code, we can see that ctl_cyrusdb does not
touch deliver.db and it is not possible to force checkpoints on or off
within lmtpd. Ideally we want to schedule the checkpointing to a "less
sociable" time.
On our setup, the checkpoint runs every c
Sorry, I'm resurrecting an old thread:
Bron Gondwana writes:
> On Tue, Sep 29, 2009 at 04:29:30PM +0200, Carles Xavier Munyoz Baldó wrote:
>> Hello,
>> May I put the database file deliver.db in the /dev/shm partition.
>>
>> I have disabled duplicatesuppressio
On Tue, Sep 29, 2009 at 04:29:30PM +0200, Carles Xavier Munyoz Baldó wrote:
> Hello,
> May I put the database file deliver.db in the /dev/shm partition.
>
> I have disabled duplicatesuppression and I believe that I will save lot of
> I/O
> requests to my hard drives if I put t
Hello,
May I put the database file deliver.db in the /dev/shm partition.
I have disabled duplicatesuppression and I believe that I will save lot of I/O
requests to my hard drives if I put this file in memory.
I'am right?
Which problems will I have with this file in memory?
I know that I
On Jan 30, 2008 1:06 PM, Sven Juergensen (KielNET)
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi list,
>
> I could use an overview of how
> cyr_expire and the entry
> ~ delprunecmd="/usr/sbin/cyr_expire -E 3"
> in the cyrus.conf within the START
> secti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi list,
I could use an overview of how
cyr_expire and the entry
~ delprunecmd="/usr/sbin/cyr_expire -E 3"
in the cyrus.conf within the START
section works.
Background is, that for some
reason, every now and then cyrus
decides that it is a go
Hi,
We recently encountered a problem with our Cyrus installation involving
the checkpoint/recovery of the deliver.db file.
We are running Cyrus 2.3.8 on Solaris 10. The server houses about
28,000 users, with a large volume of email. After our latest round of
patching, we ended up removing
At Fri, 13 Apr 2007 11:40:25 -0400, Derek T. Yarnell wrote:
Subject: Re: remove entry from deliver.db
>
> On Thu, 2007-04-12 at 13:40 -0400, Greg A. Woods wrote:
> >
> > If the user accidentally deletes a message then restoring it from
> > backups should be no differ
On Fri, Apr 13, 2007 at 11:25:08AM -0700, Andrew Morgan wrote:
> On Fri, 13 Apr 2007, Derek T. Yarnell wrote:
>
> >On Thu, 2007-04-12 at 13:40 -0400, Greg A. Woods wrote:
> >>At Thu, 12 Apr 2007 11:32:49 -0400, Derek T. Yarnell wrote:
> >>Subject: remove entry from
On Fri, 13 Apr 2007, Derek T. Yarnell wrote:
On Thu, 2007-04-12 at 13:40 -0400, Greg A. Woods wrote:
At Thu, 12 Apr 2007 11:32:49 -0400, Derek T. Yarnell wrote:
Subject: remove entry from deliver.db
Is there a way to remove an entry from the deliver.db? Like a
spam/virus solution
On Thu, 2007-04-12 at 13:40 -0400, Greg A. Woods wrote:
> At Thu, 12 Apr 2007 11:32:49 -0400, Derek T. Yarnell wrote:
> Subject: remove entry from deliver.db
> >
> > Is there a way to remove an entry from the deliver.db? Like a
> > spam/virus solution quarantined a messa
At Thu, 12 Apr 2007 11:32:49 -0400, Derek T. Yarnell wrote:
Subject: remove entry from deliver.db
>
> Is there a way to remove an entry from the deliver.db? Like a
> spam/virus solution quarantined a message, we delivered it into the
> cyrus mailbox and user deleted it. We tried t
Is there a way to remove an entry from the deliver.db? Like a
spam/virus solution quarantined a message, we delivered it into the
cyrus mailbox and user deleted it. We tried to re-deliver the message
and it now gets caught in the duplicate checker.
Thanks,
derek
--
---
Derek T. Yarnell
On Tue, 2006-08-29 at 11:58 -0400, Shelley Waltz wrote:
> my distro (cyrus-imapd-2.2.3-4) does not appear to have db_recover?
It's from the Berkeley DB tools; db4-utils on RHEL.
Wil
--
Wil Cooley <[EMAIL PROTECTED]>
Naked Ape Consulting, Ltd
signature.asc
Description: This is a digitally signe
On Tue, 2006-08-29 at 11:22 -0400, Shelley Waltz wrote:
> Aug 24 10:50:33 chipmunk lmtpunix[18963]: DBERROR: opening
> /var/lib/imap/deliver.db: Cannot allocate memory
> Aug 24 10:50:33 chipmunk lmtpunix[18963]: DBERROR: opening
> /var/lib/imap/deliver.db: cyrusdb error
> Aug 24 10
On 29 Aug 2006, at 11:22, Shelley Waltz wrote:
My question is - should I convert the deliver.db to skiplist? If I
simply
move it elsewhere and change the imapd.conf to use a deliver.db in
skiplist
and restart, what is lost? Surely this huge db contains information
necessary and useful to
my distro (cyrus-imapd-2.2.3-4) does not appear to have db_recover?
Rafael Alcalde said:
> Use db_recover
>
> Shelley Waltz wrote:
>> I have read many threads regarding issues with deliver.db being in
>> Berkeley
>> DB format. I am running cyrus-imapd-2.2.3-4
Use db_recover
Shelley Waltz wrote:
I have read many threads regarding issues with deliver.db being in Berkeley
DB format. I am running cyrus-imapd-2.2.3-4 on Redhat AS3. I have not
had any issues with deliver.db until last week. I have about 200 accounts
with
most at 250MB, some at
I have read many threads regarding issues with deliver.db being in Berkeley
DB format. I am running cyrus-imapd-2.2.3-4 on Redhat AS3. I have not
had any issues with deliver.db until last week. I have about 200 accounts
with
most at 250MB, some at 500MB and a few at 1GB.
The issue started with
ve found a lot of problems with all the databases from cyrus:
deliver.db, etc.
In /var/log/maillog we see:
DBERROR db4: Logging region out of memory; you may need to increase its
size
Aug 6 11:18:42 mail1 lmtpunix[27875]: DBERROR: opening
/var/lib/imap/deliver.db: Cannot allocate memory
On Wed, 2006-08-09 at 19:57 +0200, Rafael Alcalde wrote:
> I have found a lot of problems with all the databases from cyrus:
> deliver.db, etc.
>
> In /var/log/maillog we see:
> DBERROR db4: Logging region out of memory; you may need to increase its
> size
>
> Aug 6
I have found a lot of problems with all the databases from cyrus:
deliver.db, etc.
In /var/log/maillog we see:
DBERROR db4: Logging region out of memory; you may need to increase its
size
Aug 6 11:18:42 mail1 lmtpunix[27875]: DBERROR: opening
/var/lib/imap/deliver.db: Cannot allocate
Hi!
That's the duplicate delivery database.
http://cyrusimap.web.cmu.edu/twiki/bin/view/Cyrus/DuplicateDeliveryExplained
Best,
Daniel
Sujit Choudhury schrieb am 14.06.2006 11:01:
> We recently had some problem with deliver.db which stopped e-mail being
> delivered and stopped lmptd
We recently had some problem with deliver.db which stopped e-mail being
delivered and stopped lmptd.
I would like to know what is the function of deliver.db.
Many thanks
Sujit Choudhury
University of Westminster
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http
basically duplicate suppression might miss a few messages (since
you've deleted what it does its comparison against).
Also, I think it resets any state associated with vacation.
e.g. Someone who has already gotten a vacation auto-response, may get
another one after the deliver.db is de
If I hacked our init script to delete deliver.db before starting Cyrus
IMAPD, what adverse consequences would there be, if any? We recently
were bitten by deliver.db corruption when our mail server went down
ungracefully.
Thanks in advance.
Karl Boyken
--
Karl Boyken, system administrator
faster random lookups.
I'd suggest finding out what's causing your berkeleydb corruption. You
might just need to upgrade the version of BDB libs in your system. I run
BDB based deliver.db, etc, on several large mail clusters (1million+/day
each delivered) and have no corruption issu
ption with berkeley.
For random lookups, such as deliver.db and tls_sessions.db, berkeley is
faster. For enumerating the database, such as performing an IMAP LIST
command, skiplist is faster.
--On Sunday, September 25, 2005 11:08:28 AM +0200 [EMAIL PROTECTED] wrote:
Brenden Conte wrote:
Skiplist doesn't have fast lookups? I admit to not knowing the intricacies
of the various formats, but i thought skiplist and Berkeley were at least
comparable, as the opinion i've seen has been that skiplist is better,
especially when encountering corruption with berkeley.
Also, that is not
Brenden Conte wrote:
> Using RPM version of 2.2.10 and Berkeley DB 4.1.25...
>
> We've run into problems the last few nights with corruption of the
> duplicate delivery database (delivery.db). I tried disabling it, however
> that caused processes to fail to communicate to the local lmtp socke
Using RPM version of 2.2.10 and Berkeley DB 4.1.25...
We've run into problems the last few nights with corruption of the
duplicate delivery database (delivery.db). I tried disabling it, however
that caused processes to fail to communicate to the local lmtp sockets for
some reason. We do enj
:[EMAIL PROTECTED] Auftrag von Andreas
Gesendet: Dienstag, 13. April 2004 18:45
An: Achim Altmann
Cc: [EMAIL PROTECTED]
Betreff: Re: need help please !!! Problem with deliver.db and
/var/imap/db
On Tue, Apr 13, 2004 at 06:29:31PM +0200, Achim Altmann wrote:
> Hello,
>
> first thank's.
&
On Tue, Apr 13, 2004 at 06:29:31PM +0200, Achim Altmann wrote:
> Hello,
>
> first thank's.
> Ok, maby is a bug in redhat berkeley-db but
>
> this system runs over 1 year fine now i have this big problem the first time
>
> It's also a bug in redhat's berkeley-db with cyrus?
I'm sorry, it see
PM -, Achim Altmann wrote:
Apr 13 15:50:17 alpha1 ctl_deliver[30675]: DBERROR: opening
/var/imap/deliver.db: Invalid argument
Apr 13 15:50:17 alpha1 ctl_deliver[30675]: DBERROR: opening
/var/imap/deliver.db: cyrusdb error
I vaguely remember seeing this error message in bug re
On Tue, Apr 13, 2004 at 02:29:49PM -, Achim Altmann wrote:
> Apr 13 15:50:17 alpha1 ctl_deliver[30675]: DBERROR: opening
> /var/imap/deliver.db: Invalid argument
> Apr 13 15:50:17 alpha1 ctl_deliver[30675]: DBERROR: opening
> /var/imap/deliver.db: cyrusdb error
I vaguely remember
Hello
i use cyrus-imapd-2.1.10 with sasl on redhat-8.0
on an XFS-Filesystem
My berkeley-db is
db4-4.0.14-14
db4-devel-4.0.14-14
i have now problems with th /var/imap/db and other db\'s like deliver.db
Apr 13 15:50:17 alpha1 ctl_deliver[30675]: DBERROR: opening
/var/imap/deliver.db: In
On Thu, 6 Nov 2003, Igor Brezac wrote:
> Your expire process is not running properly. Please see my previous post:
> http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&msg=25637
Thanks for the information. I'll try it as soon as possible.
Do you know if this db enviroment set
On Thu, 6 Nov 2003, Leena Heino wrote:
> On Tue, 4 Nov 2003, Igor Brezac wrote:
>
> > Is your deliver.db continually growing?
>
> Yes it is. In just a couple of days it has grown from 180M to 195M
>
Your expire process is not running properly. Please see my previous post:
h
On Tue, 4 Nov 2003, Igor Brezac wrote:
> Is your deliver.db continually growing?
Yes it is. In just a couple of days it has grown from 180M to 195M
--
Leena Heino University of Tampere / Computer Centre
( liinu at uta.fi ) ( http://www.uta.fi/laitokset/tkk )
oblem with the setup of the sleepycat
enviroment, but I have not been able to track the problem down. Note that
this is DB 4.1.25 issue only.
cd $configdirectory
master
-Igor
> Igor Brezac a écrit:
>
> >On Tue, 4 Nov 2003, Leena Heino wrote:
> >
> >
> >
> >&g
file).
Now, the size is large because of traffic but stable. I have reduce the expiring
delay to 2 days.
Igor Brezac a écrit:
On Tue, 4 Nov 2003, Leena Heino wrote:
Is it normal that tls_sessions.db, deliver.db and db-directories seem to
get quite large. At the moment tls_sessions.db
On Tue, 4 Nov 2003, Leena Heino wrote:
> Is it normal that tls_sessions.db, deliver.db and db-directories seem to
> get quite large. At the moment tls_sessions.db is about 50kB, deliver.db
> is about 174MB and db and db.backup directories are about 1.3G each.
>
> System info
Is it normal that tls_sessions.db, deliver.db and db-directories seem to
get quite large. At the moment tls_sessions.db is about 50kB, deliver.db
is about 174MB and db and db.backup directories are about 1.3G each.
System information:
name : Cyrus IMAPD
version: v2.1.15 2003/08/15 19:34
d
> just copies
> it to a different disk occasionally. So, I'm assuming in this case that I wouldn't
> need recovery using ctl_cyrusdb at all, since we don't care about the
> deliver.db file's recovery. Am I correct?
I would not unilaterally stop running ctl_cyr
Rob Siemborski wrote:
On Wed, 15 Oct 2003, Ben Carter wrote:
First of all we have duplicate delivery suppression turned off.
However, deliver.db still seems to be maintained. I saw a post about
it being needed for sieve too but we don't plan to use sieve either. My
question is,
On Wed, 15 Oct 2003, Ben Carter wrote:
> First of all we have duplicate delivery suppression turned off.
> However, deliver.db still seems to be maintained. I saw a post about
> it being needed for sieve too but we don't plan to use sieve either. My
> question is, can I totall
Cyrus: v2.1.15
OS: Solaris 8
Berkeley DB 4.1.25
I believe I read all of the recent threads on deliver.db issues in the
archives for this mailing list, but I still have some questions:
First of all we have duplicate delivery suppression turned off.
However, deliver.db still seems to be
Thanks to everyone for their information...
I was keying in on the deliver.db because when we initially converted
to cyrus this database was a killer. I turned it off and things have
been better. That is until the "student test load" returned.
Now it looks like the mailboxes.db file is
I was also wondering this, as I am experiencing the same thing.
> -Original Message-
> From: Brian K. Becknell [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 18, 2003 11:50 AM
> To: [EMAIL PROTECTED]
> Subject: deliver.db help/understanding needed.
>
>
> Good
On Mon, 18 Aug 2003, Brian K. Becknell wrote:
> I noticed something today
> I have imapd.conf: duplicatesuppression: no
> but I still have a /var/imap/deliver.db and it's time stamp indicated that
[snip]
> does this make sense??
Yes, the duplicate delivery database is still
Good Morning.
I noticed something today
I have imapd.conf: duplicatesuppression: no
but I still have a /var/imap/deliver.db and it's time stamp indicated that
it is still being accessed/written to.
lsof of the lmtp process shows it is also accessed.
I am running
cyrus-imapd-2.1.12
does
On Fri, 2003-07-25 at 19:17, Ken Murchison wrote:
> Jeff Warnica wrote:
> > To finish that statement "... so it can make a half decent attempt at
> > single message store".
>
> Actually, its not used for single instance store at all. This happens
> before the message-id is committed to the datab
Jeff Warnica wrote:
To finish that statement "... so it can make a half decent attempt at
single message store".
Actually, its not used for single instance store at all. This happens
before the message-id is committed to the database. Hence, it only
works for recipients that are part of the s
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> On Fri, 25 Jul 2003, Mike Cathey wrote:
>> I just wanted to see if it was normal to see the deliver db get this
>> big...
>
>> SNIP
>> -rw---1 cyrusmail 50M Jul 25 11:04 d
Tarjei Huse wrote:
On Fri, 2003-07-25 at 17:46, Henrique de Moraes Holschuh wrote:
On Fri, 25 Jul 2003, Mike Cathey wrote:
I just wanted to see if it was normal to see the deliver db get this
big...
It will get as big as you let it to. Depends on frequency of prunning, and
the ammount of traf
To finish that statement "... so it can make a half decent attempt at
single message store".
On Fri, 25 Jul 2003, Rob Siemborski wrote:
> On Fri, 25 Jul 2003, Mike Cathey wrote:
>
> > I just wanted to see if it was normal to see the deliver db get this
> > big...
>
> Yes. It's keeping track o
On Fri, 2003-07-25 at 17:46, Henrique de Moraes Holschuh wrote:
> On Fri, 25 Jul 2003, Mike Cathey wrote:
> > I just wanted to see if it was normal to see the deliver db get this
> > big...
> It will get as big as you let it to. Depends on frequency of prunning, and
> the ammount of traffic throug
On Fri, 25 Jul 2003, Mike Cathey wrote:
> I just wanted to see if it was normal to see the deliver db get this
> big...
> SNIP
> -rw---1 cyrusmail 50M Jul 25 11:04 deliver.db
> SNIP
>
It will get as big as you let it to. Depends on fre
tabase just doesn't bother deallocating for performance reasons).
For example,
mail4:sun4x_58:~# ls -l /imap/conf/deliver.db
-rw-r- 1 cyrusstaff90103808 Jul 25 11:36 /imap/conf/deliver.db
Which is just one of our 5 backends.
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I just wanted to see if it was normal to see the deliver db get this
big...
SNIP
-rw---1 cyrusmail 50M Jul 25 11:04 deliver.db
SNIP
Cheers,
Mike
signature.asc
Description: This is a digitally signed message part
m lmtpd[13549]: DBERROR: opening /var/imap/deliver.db: Not
> enough space
> Jul 15 09:45:23 tom lmtpd[13549]: DBERROR: opening /var/imap/deliver.db:
> cyrusdb error
> Jul 15 09:45:23 tom lmtpd[13549]: lmtpd: unable to init duplicate delivery
> database
>
> I am not too familiar with t
We are running the following Cyrus-IMAP 2.1.12/Cyrus-SASL 2.1.13
We have been having a recurring error show up in our message logs..
Jul 15 09:45:23 tom lmtpd[13549]: DBERROR: opening /var/imap/deliver.db: Not
enough space
Jul 15 09:45:23 tom lmtpd[13549]: DBERROR: opening /var/imap/deliver.db
ctl_cyrusdb[7772]: checkpointing cyrus databases
Jul 12 10:55:11 seth ctl_cyrusdb[7772]: done checkpointing cyrus
databases
Jul 12 10:55:11 seth lmtpd[7774]: DBERROR db4: operation not permitted
during recovery.
Jul 12 10:55:11 seth lmtpd[7774]: DBERROR: opening
/var/lib/imap/deliver.db: Invalid argument
Jul
86 matches
Mail list logo
