On Tue, Mar 08, 2011 at 04:30:45PM +0100, Eric Luyten wrote:
> On Tue, March 8, 2011 4:24 pm, Gary Mills wrote:
> > We are running cyrus-imapd-2.3.8 with this entry in /etc/cyrus.conf:
> >
> > delprune cmd="cyr_expire -E 3" at=0400
> >
> > I believe this is the default setting. Is there any r
On Tue, March 8, 2011 4:24 pm, Gary Mills wrote:
> We are running cyrus-imapd-2.3.8 with this entry in /etc/cyrus.conf:
>
>
> delprune cmd="cyr_expire -E 3" at=0400
>
> I believe this is the default setting. Is there any reason to keep
> message IDs around for three days? I'm wondering if re
We are running cyrus-imapd-2.3.8 with this entry in /etc/cyrus.conf:
delprune cmd="cyr_expire -E 3" at=0400
I believe this is the default setting. Is there any reason to keep
message IDs around for three days? I'm wondering if reducing it to
one day will improve performance for local d
Hi,
Am Mittwoch, den 21.04.2010, 00:37 +0200 schrieb Marcus:
[...]
> I did clean /var/lib/cyrus/db and deleted /var/lib/cyrus/deliver.db
> after stopping cyrus. But after three day I got the same error
[...]
I've checked the logs again tonight and the "IOERROR: lock_shared" only
comes up while du
Hi,
Am Dienstag, den 06.04.2010, 18:13 -0500 schrieb Dan White:
> On 07/04/10 00:45 +0200, Marcus wrote:
> >I've restarted cyrus and got a "recovery /var/lib/cyrus/deliver.db:
> >found partial txn, not replaying". Delivering is working fine and
> >dupelim check too. Could someone confirm, that Sim
On 07/04/10 00:45 +0200, Marcus wrote:
>I've restarted cyrus and got a "recovery /var/lib/cyrus/deliver.db:
>found partial txn, not replaying". Delivering is working fine and
>dupelim check too. Could someone confirm, that Simon's idea to clean
>up /var/lib/cyrus/db and remove deliver.db is _not_
On Wed, 7 Apr 2010, Marcus wrote:
>> Just guessing, maybe you have to stop cyrus, clean up the $configdir/db
>> directory, remove the existing deliver.db file and start up again.
>> Maybe you have some BDB stuff left over in ../db.
>
> I've restarted cyrus and got a "recovery /var/lib/cyrus/delive
red /var/lib/cyrus/deliver.db: Interrupted system call
> > Apr 5 04:12:48 server cyrus/lmtpunix[8473]: DBERROR:
> > opening /var/lib/cyrus/deliver.db: cyrusdb error
> > Apr 5 04:12:48 server cyrus/lmtpunix[8473]: FATAL: lmtpd: unable to
> > init duplicate delivery database
&
/deliver.db: Interrupted system call
> > Apr 5 04:12:48 server cyrus/lmtpunix[8473]: DBERROR:
> > opening /var/lib/cyrus/deliver.db: cyrusdb error
> > Apr 5 04:12:48 server cyrus/lmtpunix[8473]: FATAL: lmtpd: unable to
> > init duplicate delivery database
> > Apr
RROR:
> opening /var/lib/cyrus/deliver.db: cyrusdb error
> Apr 5 04:12:48 server cyrus/lmtpunix[8473]: FATAL: lmtpd: unable to
> init duplicate delivery database
> Apr 5 04:12:48 server cyrus/master[21374]: process 8473 exited, status
> 75
> Apr 5 04:12:48 server cyrus/master[21
/deliver.db: cyrusdb error
Apr 5 04:12:48 server cyrus/lmtpunix[8473]: FATAL: lmtpd: unable to
init duplicate delivery database
Apr 5 04:12:48 server cyrus/master[21374]: process 8473 exited, status
75
Apr 5 04:12:48 server cyrus/master[21374]: service lmtpunix pid 8473 in
READY state: terminated
ed Cyrus duplicate suppression by adding the
>> following line to my imapd.conf :
>>
>> duplicatesuppression: 0
>>
>>
>>
>> Somewhat naively I thought that Cyrus wouldn't be writing the duplicate
>> delivery database anymore, but this is no
:
duplicatesuppression: 0
Somewhat naively I thought that Cyrus wouldn't be writing the duplicate
delivery database anymore, but this is not the case.
Cyrus still needs to write to the delivery database, e.g. for vacation
messages. But it will deliver messages even if they have the same
message-id.
Is
thought that Cyrus wouldn't be writing the duplicate
delivery database anymore, but this is not the case.
Is there, other than by patching the C code, a way to disable writing
delivery.db ?
This is a Cyrus 2.2 system, upgrading to 2.3 this summer.
Regards,
Eric Luyten, Computing Centre VU
init duplicate delivery
database
unable to initialize inviromnent loc
All these errors keep going on and on. I remove the contents of the db
folder and deliver.db and restarted cyrus-imapd. I did not help. These
mistakes stopped occuring when I removed /var/lib/imap/socket folder but
I was
On Fri, 15 Apr 2005, Martine James (02 23 23 71 31) wrote:
I installed Cyrus one year ago and it used to work nicely with option
"duplicatesuppression" as set by default (YES)
Things went wrong four days ago with this message:
Apr 14 12:00:04 machine.etu.univ-rennes1.fr pop3[7118]: [ID 729713
loc
569]: [ID 157947
local6.error] FATAL: lmtpd: unable to init duplicate delivery database
this a sendmail log:
Apr 14 14:28:37 machine.etu.univ-rennes1.fr postfix/lmtp[10031]: [ID 197553
mail.info] 8D46E4D: to=<[EMAIL PROTECTED]>, orig_to=<[EMAIL PROTECTED]>,
relay=none, delay=0, status=d
On Fri, 20 Aug 2004, Rob Carter wrote:
Gentlefolk,
Does anyone have experiences they'd be willing to share with combatting
deadlocks within a BDB 3.3 duplicate delivery database on a high-traffic
Cyrus v2.1.16 (or earlier 2.1.x) server? We're running a 60,000+ user/1.2
million m
,
>
> Does anyone have experiences they'd be willing to share with combatting
> deadlocks within a BDB 3.3 duplicate delivery database on a high-traffic Cyrus
> v2.1.16 (or earlier 2.1.x) server? We're running a 60,000+ user/1.2 million
> message/day Cyrus postoffice on a
Gentlefolk,
Does anyone have experiences they'd be willing to share with combatting
deadlocks within a BDB 3.3 duplicate delivery database on a high-traffic Cyrus
v2.1.16 (or earlier 2.1.x) server? We're running a 60,000+ user/1.2 million
message/day Cyrus postoffice on an 8-way Sola
ap/deliver.db: Invalid argument
> Nov 18 13:49:09 tux lmtpd[19879]: DBERROR: opening
> /var/lib/imap/deliver.db: cyrusdb error
> Nov 18 13:49:09 tux lmtpd[19879]: FATAL: lmtpd: unable to init
> duplicate
> delivery database
> Nov 18 13:49:09 tux ctl_cyrusdb[19874]: done checkpointing
18 13:49:09 tux lmtpd[19879]: DBERROR: opening
/var/lib/imap/deliver.db: Invalid argument
Nov 18 13:49:09 tux lmtpd[19879]: DBERROR: opening
/var/lib/imap/deliver.db: cyrusdb error
Nov 18 13:49:09 tux lmtpd[19879]: FATAL: lmtpd: unable to init duplicate
delivery database
Nov 18 13:49:09 tux
18 13:49:09 tux lmtpd[19879]: DBERROR: opening
/var/lib/imap/deliver.db: Invalid argument
Nov 18 13:49:09 tux lmtpd[19879]: DBERROR: opening
/var/lib/imap/deliver.db: cyrusdb error
Nov 18 13:49:09 tux lmtpd[19879]: FATAL: lmtpd: unable to init duplicate
delivery database
Nov 18 13:49:09 tux
Hy!
On 04-Sep-2001 Scott Adkins wrote:
>> You definitely need to run recovery on your duplicate delivery
>> database. I might just delete the database entirely; since the
>> duplicate delivery database isn't transactional, it can't guarantee
>> consistency, a
Date: Tue, 04 Sep 2001 18:31:10 -0400
From: Scott Adkins <[EMAIL PROTECTED]>
We stopped the server and nuked the delivery files altogether. This only
worked for 2 days, however, and now we are back to where we were. We see
a constant stream of duplicate delivery database
nd so forth... hitting all the delivery databases ]
>[ there is a mixture of duplicate_check and duplicate-mark entries
> also ]
>
> You definitely need to run recovery on your duplicate delivery
> database. I might just delete the database entirely; since the
> duplicate
]
You definitely need to run recovery on your duplicate delivery
database. I might just delete the database entirely; since the
duplicate delivery database isn't transactional, it can't guarantee
consistency, and there's no critical database in it.
To run recover, you must kill at l
We are seeing problems in our log file with regards to our duplicate
delivery database. They are as follows:
lmtpd[19330]: duplicate_mark: error setting
/536836816: Invalid argument
lmtpd[19330]: duplicate_check: opening /var/imap/deliverdb/deliver-m.db:
Invalid argument
lmtpd[19330
28 matches
Mail list logo
