I know that I could just copy the
mailboxes.db file from the master to the replica, then manually move
the mailboxes that are in the "wrong" place to the "right" place, but
this seems a little drastic. Any way I can just tell the replica to
update the location of the mailbox on
know about the mupdate server in it's role as a replica.
What are my options here - I know that I could just copy the
mailboxes.db file from the master to the replica, then manually move
the mailboxes that are in the "wrong" place to the "right" place, but
this seems a little dras
Hi,
[4:11pm] hagedose: user.testuser-clotho1.diesisteintest 16 (null)
This sounds like it's the tombstone entry for the deleted mailbox (i.e. a
record that there used to be a mailbox with that name). I believe
tombstones are relatively new, in which case the master server might not
have one
Hi,
> [4:11pm] hagedose: user.testuser-clotho1.diesisteintest 16 (null)
This sounds like it's the tombstone entry for the deleted mailbox (i.e. a
record that there used to be a mailbox with that name). I believe tombstones
are relatively new, in which case the master server might not
Hi,
I asked this question on IRC yesterday, but I didn't get any response.
Maybe someone here knows?
[4:08pm] hagedose: Is it expected behavior that a replicated RENAME leaves
an „empy“ mboxlist entry?
[4:08pm] hagedose: We’re experimenting with replication from a 2.4.20
server to a 3.0.5
Hello,
in case anybody interested, I managed to fix mailboxes.db by this
technic (I have no shared folders, groups, complex permissions etc)
1. create plain dump file:
cyr_dbtool /mailboxes.db twoskip show | perl -n -e 'if (
~/^([^\t]+)\t%\(A %\(([^\s]+) ([^\)]+)/ ) { print "$1\t0 de
On 10/20/2017 11:52 AM, Deniss wrote:
Hello,
I run cyrus imap 2.5.11.
Somehow mailboxes.db become corrupted.
running `ctl_mboxlist -d` leads to segfault, backtrace below.
How can I recover mailboxes.db ?
Backtrace
#0 0x007d43e12952 in printf (__fmt=0x7d43e143c2 "%s\t%d %s %s\n"
Hello,
I run cyrus imap 2.5.11.
Somehow mailboxes.db become corrupted.
running `ctl_mboxlist -d` leads to segfault, backtrace below.
How can I recover mailboxes.db ?
Backtrace
#0 0x007d43e12952 in printf (__fmt=0x7d43e143c2 "%s\t%d %s %s\n")
at /usr/include/bits/stdio2.h:104
#
Am Montag, den 15.05.2017, 07:59 -0300 schrieb Patrick Boutilier:
> rm -fr if you are 100% sure you don't need the files. Move if not 100%
> sure .:-)
>
> Since cyrus doesn't know about the folders in mailboxes.db it shouldn't
> care either way.
That's working.
Thanks
Marcus
ve if not 100%
sure .:-)
Since cyrus doesn't know about the folders in mailboxes.db it shouldn't
care either way.
Ciao!
Marcus
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.
Hi,
Am Montag, den 15.05.2017, 07:34 -0300 schrieb Patrick Boutilier:
> That will probably work. You can see what will happen by using -n also .
> Another option is just to remove the subfolders from the filesystem
> using rm .
I just tried:
su - cyrus -c " /usr/lib/cyrus/bin/reconstruct -r
are listed in mailboxes.db, which is
correct.
What's the best way to remove those old folders permanently from the
filesystem on the master? Can I use reconstruct with -O option (Delete
odd files)?
That will probably work. You can see what will happen by using -n also .
Another option is just
some more info:
I did some further checks:
those messages are not shown by unexpunge -l. I get a "Failed to open
mailbox" if I check the delete subdirs, which is correct to my mind,
because these mailbox don't exist any more.
The delete subdirs didn't show up in DELETED.user. I use
Hi,
some time ago I removed several big sized subfolders in a mailbox using
my mail client. Yesterday I recognized that for some reasons those
folders are still on the file system on master, but not on replica side.
Non of those deleted folders are listed in mailboxes.db, which is
correct
umentation is a work in progress.
To see how to apply annotations, see the manpage for cyradm(8).
Next: Suppose I've completely lost /var/imap/mailboxes.db as well as
/var/imap/db.backup1 and /var/imap/db.backup2. Is there any way to
recover from this? Given that
/usr/lib/cyrus/bin/reco
idea what this is used for. Can someone give me an
example of a mailbox or server annotation.
Next: Suppose I've completely lost /var/imap/mailboxes.db as well as
/var/imap/db.backup1 and /var/imap/db.backup2. Is there any way to
recover from this? Given that
/usr/lib/cyrus/bin/reconstruct
> Sorry, I really don't have a clue. 2.5 does have a different mailboxes.db
> format, so it's a bit more CPU intensive. The real massive win for CPU
> usage is going to come with reverse ACLs:
Thanks for the response in the first place! I'm sorry to push this topic
continuously because
I directly asked Bron, but no response as well.
Sorry, I really don't have a clue. 2.5 does have a different mailboxes.db
format, so it's a bit more CPU intensive. The real massive win for CPU usage
is going to come with reverse ACLs:
https://blog.fastmail.com/2015/12/05/reverse-acls-making-imap-l
On 17/11/16 14:00, Deniss via Info-cyrus wrote:
> Hello,
>
> I trying to migrate one big cyrus imap server from 2.4 to 2.5.9.
>
> I updated binaries, fix db backend in imapd.conf and converted
> mailboxes.db with ctl_mboxlist -d & -u to twoskip.
>
> cyrus ran fin
nd converted
mailboxes.db with ctl_mboxlist -d & -u to twoskip.
cyrus ran fine until morning when a count of simultanious sessions
started to rise.
then imapd processes become locked on mailboxes.db when logs show
something like
Nov 17 08:04:21 srv1 imap[11019]: cmdtimer:
'y...@mail.xxx<m
Hello,
I trying to migrate one big cyrus imap server from 2.4 to 2.5.9.
I updated binaries, fix db backend in imapd.conf and converted
mailboxes.db with ctl_mboxlist -d & -u to twoskip.
cyrus ran fine until morning when a count of simultanious sessions
started to rise.
then imapd proce
t; First I tried to dump the mailbox.db with ctl_mboxlist -d
> >>> /tmp/mailboxes.txt
> >>>
> >>> After deleting the wrong entry manually I wanted to reload the mailbox
> >>> again with ctl_mboxlist -u /tmp/mailboxes.txt. All operation with
> >
mboxlist -d /tmp/mailboxes.txt
>>>
>>> After deleting the wrong entry manually I wanted to reload the mailbox
>>> again with ctl_mboxlist -u /tmp/mailboxes.txt. All operation with
>>> stopped cyrus.
>>
>> Have you renamed your mailboxes.db after using -d and befo
ed cyrus.
Have you renamed your mailboxes.db after using -d and before using -u?
Otherwise ctl_mboxlist will import your dump into the existing mailboxes.db.
And are this exactly the commands you used?
I think
ctl_mboxlist -d >/tmp/mailboxes.txt
and
ctl_mboxlist -f /tmp/mailboxes
wrote:
> Hi all,
>
> I have an unresolvable problem with one mailbox:
>
> It got an entry inside the mailboxes.db and a spool directory - but I
> can't change it or access it. I always got "invalid identifier" on cyradm.
>
> Dumping the mailbox with ctl_mboxlist
>
Hi all,
I have an unresolvable problem with one mailbox:
It got an entry inside the mailboxes.db and a spool directory - but I
can't change it or access it. I always got "invalid identifier" on cyradm.
Dumping the mailbox with ctl_mboxlist
example.com!user.kontakt.Calendar 0 (n
mailboxes.db file so that I can go about creating
the mailboxes afresh.
My question is how to do this? Looking through this list's archives,
I see that the cyr_dbtool command can be used to query and manipulate
the mailboxes.db file itself, but someone mentioned that it's best
not to modify
to get these sorts of entries removed from the
mupdate server's mailboxes.db file so that I can go about creating
the mailboxes afresh.
If you log in to mailbox-03-internal and run:
# ctl_mboxlist -d | grep ^user\.foo
is anything returned? For that matter, run this on each of your backend
Hi Dave,
Thanks for the quick, helpful response.
If you log in to mailbox-03-internal and run:
# ctl_mboxlist -d | grep ^user\.foo
is anything returned? For that matter, run this on each of your backend
servers and see if it exists anywhere.
None of the mailbox servers have any record
On 9 Jul 2013, at 22:20, Shawn Winnington-Ball swb...@uwaterloo.ca wrote:
You can force a backend to push all of its mailboxes to the mupdate master
by running ctl_mboxlist -m on the backend. If you're not 100% sure
whether you want to push every mailbox before you know what state things
, this did the trick to recreate the directory
structure on-disk and populate the mailboxes.db file on the backend.
Shawn
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo
Hi,
running 2.4.16 we noticed something that clearly isn't right. Somehow a
user managed to rename (or rather move) a folder twice at the same time.
The result is an invalid entry in mailboxes.db without the corresponding
folder in the file system. Here's what happened:
Jan 24 18:07:36
Hmf, I should've read the release notes first :( It's fixed in 2.4.17:
Fixed bug #3696: can no longer rename the same mailbox twice, which left
things in a corrupted state if you caught the race.
Sorry for the noise.
I've also filed a bug report:
Interesting, this might solve my problem, too (delayed delete makes
two copies of the mailbox in the DELETED tree). So I'm just going to
have to upgrade.
--Janne
Lainaus Sebastian Hagedorn haged...@uni-koeln.de:
Hmf, I should've read the release notes first :( It's fixed in 2.4.17:
I deleted the old folder 'folder'
from the file system and then (after it wouldn't go away from the
cyradm listing) used cyr_dbtool to manually remove it (and the
subfolders) from the mailboxes.db file. The old folders and subfolders
are now gone, however, I can't (using the IMAP client) rename
on the new set of
folders and everything worked. Now I deleted the old folder 'folder'
from the file system and then (after it wouldn't go away from the
cyradm listing) used cyr_dbtool to manually remove it (and the
subfolders) from the mailboxes.db file. The old folders and subfolders
are now gone
On Sat, May 19, 2012 at 09:51:38AM -0700, Stephen Ingram wrote:
I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
Could be sort order bugs with 2.4.13 if you don't have
improved_mboxlist_sort turned on.
I've dumped the mailboxes.db file to a flat file to look and see
on.
I've dumped the mailboxes.db file to a flat file to look and see if
there is anything in there that wasn't visible in cyradm or using
cyr_dbtool show. Everything is as expected except there are some
DELETED.user.xxx.folder entries at the top. Are you not allowed the
create folders
it (and the
subfolders) from the mailboxes.db file. The old folders and subfolders
are now gone, however, I can't (using the IMAP client) rename
'folder2' back to 'folder' as when I do, the subfolders are not
visible.
I've dumped the mailboxes.db file to a flat file to look and see if
there is anything
cyr_dbtool to manually remove it (and the
subfolders) from the mailboxes.db file. The old folders and subfolders
are now gone, however, I can't (using the IMAP client) rename
'folder2' back to 'folder' as when I do, the subfolders are not
visible.
I've dumped the mailboxes.db file to a flat file
'
from the file system and then (after it wouldn't go away from the
cyradm listing) used cyr_dbtool to manually remove it (and the
subfolders) from the mailboxes.db file. The old folders and subfolders
are now gone, however, I can't (using the IMAP client) rename
'folder2' back to 'folder
on the new set of
folders and everything worked. Now I deleted the old folder 'folder'
from the file system and then (after it wouldn't go away from the
cyradm listing) used cyr_dbtool to manually remove it (and the
subfolders) from the mailboxes.db file. The old folders and subfolders
are now
bugs with 2.4.13 if you don't have
improved_mboxlist_sort turned on.
I've dumped the mailboxes.db file to a flat file to look and see if
there is anything in there that wasn't visible in cyradm or using
cyr_dbtool show. Everything is as expected except there are some
DELETED.user.xxx.folder
^
:)
Looking at all of the files in there, several are older than the 3
days they are supposed to be. I'm guessing that means there was a bug
somewhere. I guess I should remove all of these, reconstruct the
mailboxes.db to match and then probably upgrade as Bron suggested.
No - the files will have
it (and the
subfolders) from the mailboxes.db file. The old folders and subfolders
are now gone, however, I can't (using the IMAP client) rename
'folder2' back to 'folder' as when I do, the subfolders are not
visible.
I've dumped the mailboxes.db file to a flat file to look and see if
there is anything
,
no matter what the name - hence it's hashing on:
DELETE.user.x
^
:)
Looking at all of the files in there, several are older than the 3
days they are supposed to be. I'm guessing that means there was a bug
somewhere. I guess I should remove all of these, reconstruct the
mailboxes.db to match
On Sat, May 19, 2012 at 02:02:53PM -0700, Stephen Ingram wrote:
BTW, I love 2.4. I've been using now for several months and it is such
a HUGE improvement from 2.3. Everything is faster, replication works
better, it's like a whole new program!
Just wait until you get 2.5 :) There's still lots
up */
Thanks.
It appears that mailcluster1 believes a mailbox transfer was initiated, but
has not yet completed (or failed).
This happened.
You can use cyr_dbtool to manually edit the entry in your mailboxes.db, or
remove it. See:
http://asg.andrew.cmu.edu/archive/message.php?mailbox
On 03/08/11 13:45 +0200, Frank Elsner wrote:
On Tue, 2 Aug 2011 09:56:19 -0500 Dan White wrote:
It appears that mailcluster1 believes a mailbox transfer was initiated, but
has not yet completed (or failed).
This happened.
You can use cyr_dbtool to manually edit the entry in your mailboxes.db
Hallo,
which values are possible and what is the corresponding meaning
for the Type Number in mailboxes.db?
After failed XFERs we see
- on the murder
user.richard^hildebrand 1 mailcluster1
- on mailcluster1
user.richard^hildebrand 8 mailbackend-1-febe!default
We would like to know
On 02/08/11 16:30 +0200, Frank Elsner wrote:
Hallo,
which values are possible and what is the corresponding meaning
for the Type Number in mailboxes.db?
After failed XFERs we see
- on the murder
user.richard^hildebrand 1 mailcluster1
- on mailcluster1
user.richard^hildebrand 8
Hi ,
I find some information about Cyrus Murder Mail Delivery in link:
http://www.cyrusimap.org/mediawiki/index.php/Cyrus_Murder_Mail_Delivery
This patch is already implemented in Cyrus Imap 2.3.16 ?
I try to configure to use local mailboxes.db ,
.
master
it with the MUPDATE server, but left it in reserved state in the local
(backend) mailboxes.db with mbtype=2. This means that it shows up in a
LIST or LSUB with the \NoSelect flag, and the users can't do anything with
it, including delete it.
You should be able to correct this by running ctl_mboxlist -ma
in the local
(backend) mailboxes.db with mbtype=2. This means that it shows up in a
LIST or LSUB with the \NoSelect flag, and the users can't do anything with
it, including delete it.
I know I could do some pretty heavy-handed stuff to clear this condition,
like dumping the mailboxes database
it with the MUPDATE server, but left it in reserved state in the local
(backend) mailboxes.db with mbtype=2. This means that it shows up in a
LIST or LSUB with the \NoSelect flag, and the users can't do anything with
it, including delete it.
I know I could do some pretty heavy-handed stuff to clear
hundred mailboxes where the backend created the mailbox on disk,
registered it with the MUPDATE server, but left it in reserved state
in the local (backend) mailboxes.db with mbtype=2. This means that it
shows up in a LIST or LSUB with the \NoSelect flag, and the users can't
do anything
On 08/24/2010 01:17 PM, Michael Bacon wrote:
Definitely something I hadn't thought of, but in this case, the faulty
mbtype appears to be in the mailboxes.db on the backend server, not the
mupdate server. I don't think an MUPDATE command would change that,
would it?
If your mupdate master
--On August 24, 2010 1:22:53 PM -0400 Dave McMurtrie
dav...@andrew.cmu.edu wrote:
On 08/24/2010 01:17 PM, Michael Bacon wrote:
Definitely something I hadn't thought of, but in this case, the faulty
mbtype appears to be in the mailboxes.db on the backend server, not the
mupdate server. I
cyr_dbtool to edit the entry on the backend.
For example:
# cyr_dbtool /imap/conf/mailboxes.db skiplist get user.testuser3
2 u1 testuser3 lrswipkxtecda
# cyr_dbtool /imap/conf/mailboxes.db skiplist set user.testuser3 0 u1
testuser3lrswipkxtecda
Set is in the form state location username acl
the entry on the backend.
For example:
# cyr_dbtool /imap/conf/mailboxes.db skiplist get user.testuser3
2 u1 testuser3 lrswipkxtecda
# cyr_dbtool /imap/conf/mailboxes.db skiplist set user.testuser3 0 u1
testuser3lrswipkxtecda
Set is in the form state location username acl. Importantly
On Mon, 24 Nov 2008, Simon Matter wrote:
I just wanted to follow up on this thread, rather than leaving it hanging.
It seems there was a more serious issue, which ultimately lead to the
failure we experienced, with our murder setup. Specifically our
internal DNS servers, were having
the mailboxes.db to frontends. If the
frontends are updating, it is not apparent. I could not verify that
either of them were synching from the master after the mupdate master
synch. Which is why I copied them to the frontends to speed things up.
I've tried this in the past
, Wolfe, Eric G wrote:
We are using skiplist, I copied the mailboxes.db to frontends. If the
frontends are updating, it is not apparent. I could not verify that
either of them were synching from the master after the mupdate master
synch. Which is why I copied them to the frontends to speed
started up the
front-ends, per the instructions. The front-ends failed to synch with
the mupdate master.
So in an effort to try something else. I figured if the mailboxes.db on
the front-ends and the master are the same format, I could just shutdown
the mupdate master; copy the mailboxes.db
to skiplist?
I made backup copies of all files deleted, renaming them
$filename.corrupt. I did this on each server, recovered on the
backends, and let it push the updates to the mupdate server.
Did you also convert mupdate master to skiplist?
Manually
recovered mailboxes.db on the frontends
a good copy on the mupdate master. In what
way do the frontends fail to sync?
So in an effort to try something else. I figured if the
mailboxes.db on
the front-ends and the master are the same format, I could just
shutdown
the mupdate master; copy the mailboxes.db file over
cyrus-imapd-2.2.12-9.RHEL4
From: Wesley Craig [EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 10:08 AM
To: Eric G.Wolfe
Cc: info-cyrus@lists.andrew.cmu.edu
Subject: Re: murder setup - mailboxes.db corruption - trouble recovering with
ctl_mboxlist
___
From: Wesley Craig [EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 10:27 AM
To: Eric G.Wolfe
Cc: info-cyrus@lists.andrew.cmu.edu
Subject: Re: murder setup - mailboxes.db corruption - trouble recovering with
ctl_mboxlist
On 20 Nov 2008, at 07:39, Eric G
On Thu, 20 Nov 2008, Wolfe, Eric G wrote:
We are using skiplist, I copied the mailboxes.db to frontends. If the
frontends are updating, it is not apparent. I could not verify that
either of them were synching from the master after the mupdate master
synch. Which is why I copied them
server, recovered on the
backends, and let it push the updates to the mupdate server. Manually
recovered mailboxes.db on the frontends, as they did not seem to be
getting updated. If I am going about this wrong, please someone point
me in the right direction for documentation on murder disaster
examination and fixes im found that mailboxes.db was
empty (144 bytes). Cyrus can start but it dont know anything about
mailboxes what stored in cyrus partition.
We look at reconstruction tool and found the magic -m option which
must reconstruct mailboxes.db parsing cyrus partition. But...
it`s dont
On Mon, 5 Mar 2007, Gregor Wenkelewsky wrote:
I don't really know about that. Here is from the log during another
controlled shutdown and reboot, of course I had to make sure that my
mailboxes.db error would not occur on every reboot. (It did not occur
again.) These are the last lines, no sign
, sadly today
it started to fail completely with this error message in mail.warn,
mail.error and syslog:
cyrus/imap[..]: DBERROR: skiplist recovery /var/lib/cyrus/mailboxes.db:
0090 should be ADD or DELETE
cyrus/imap[..]: DBERROR: opening /var/lib/cyrus/mailboxes.db: cyrusdb error
You'll
,
mail.error and syslog:
cyrus/imap[..]: DBERROR: skiplist recovery /var/lib/cyrus/mailboxes.db: 0090
should be ADD or DELETE
cyrus/imap[..]: DBERROR: opening /var/lib/cyrus/mailboxes.db: cyrusdb error
You'll need to fix the corruption of the mailboxes.db file. It is a
skiplist format file in your
completely with this error message in mail.warn,
mail.error and syslog:
cyrus/imap[..]: DBERROR: skiplist recovery /var/lib/cyrus/mailboxes.db: 0090
should be ADD or DELETE
cyrus/imap[..]: DBERROR: opening /var/lib/cyrus/mailboxes.db: cyrusdb error
You'll need to fix the corruption of the mailboxes.db
/lib/cyrus/mailboxes.db: 0090
should be ADD or DELETE
cyrus/imap[..]: DBERROR: opening /var/lib/cyrus/mailboxes.db: cyrusdb error
There was a post by Florin Andrei on March 12 2004 in which he described a
similar problem and a solution, but his setting is much different to mine and I
can't just
:
cyrus/imap[..]: DBERROR: skiplist recovery /var/lib/cyrus/mailboxes.db: 0090
should be ADD or DELETE
cyrus/imap[..]: DBERROR: opening /var/lib/cyrus/mailboxes.db: cyrusdb error
There was a post by Florin Andrei on March 12 2004 in which he described
a similar problem and a solution, but his
On Sun, 28 Jan 2007, peter pilsl wrote:
I manually deleted the whole content of spool/user/SOMEUSER to get rid of
all the mails and subboxes in it.
Big Mistake.
Cause cyrus still knows about all the subboxes that this user was supposed to
have. How do I tell cyrus that there are no
I manually deleted the whole content of spool/user/SOMEUSER to get rid of all
the mails and subboxes in it.
Big Mistake.
Cause cyrus still knows about all the subboxes that this user was supposed to
have. How do I tell cyrus that there are no subboxes anymore.
I already tried to delete
Hi.
We are going to upgrade to Cyrus v2.3 sometime before midsummer.
Currently, we are running an old, old version of Cyrus with a plaintext
mailboxes file. Now and again, an imapd process gets stuck and keeps the
writelock on the mailboxes file - so we have to kill the stuck process
manually
doesn't use byterange locking for plaintext mailboxes.db. It just
relies on advisory locking of the whole file, and it updates the file
atomically by creating a new version and renaming it. Running 1.5.14,
there used to be some locking issues where, much as you describe, we'd
end up having
We are going to upgrade to Cyrus v2.3 sometime before midsummer.
Currently, we are running an old, old version of Cyrus with a plaintext
mailboxes file. Now and again, an imapd process gets stuck and keeps the
writelock on the mailboxes file - so we have to kill the stuck process
manually
copy it from the old
one)
* create an empty mailboxes.db-file on the new installation
* ctl_mboxfile -u on the new installation
This will create a skipfile-style mailboxes.db - file for me. Closely monitoring
syslog will help to detect problems. I put a documentation of my
migration-process
the mailboxes.db and
seen-files with the cvt_cyrusdb-command as recommended, but I run into a strange
error:
as user cyrus I do:
$ /usr/sbin/cvt_cyrusdb /data/cyrus/config/mailboxes.db berkeley
/tmp/mailboxes.db.new skiplist
Converting from /data/cyrus/config/mailboxes.db (berkeley) to
/tmp
the mailboxes.db and
seen-files with the cvt_cyrusdb-command as recommended, but I run into a
strange
error:
as user cyrus I do:
$ /usr/sbin/cvt_cyrusdb /data/cyrus/config/mailboxes.db berkeley
/tmp/mailboxes.db.new skiplist
Converting from /data/cyrus/config/mailboxes.db (berkeley
no cyrus is using hte same berkeley DB.
I jsut plugged a new disk and the raid sarted reconstruction.
In this situation started the problem with mailboxes.db
the /var/imap/db directory does exist.
but there si also another problem
PID USERNAME PRI NICE SIZERES STATE C TIME
On Sunday 31 December 2006 00:07, RJ45 wrote:
OS is FreeBSD 5.5-STABLE
cyrus-imapd 2.2.12 installed
this problem started accouring after a RAID5 reconstruction.
What means RAID5 reconstruction? A Rebuild of a failed Disk or did you
reinitialize/reformat the Raid 5? Is the rebuild running
]: DBERROR: opening
/var/imap/mailboxes.db: Invalid argument
Dec 29 13:11:59 postino ctl_cyrusdb[2922]: DBERROR: opening
/var/imap/mailboxes.db: cyrusdb error
how can I solve this problem ?
cyrus continue to work but I have these errors on master startup and then
after I have errors like
happened before this?
Dec 29 13:11:59 postino ctl_cyrusdb[2922]: DBERROR: init() on berkeley
Dec 29 13:11:59 postino ctl_cyrusdb[2922]: DBERROR db3: environment not
yet opened
Dec 29 13:11:59 postino ctl_cyrusdb[2922]: DBERROR: opening
/var/imap/mailboxes.db: Invalid argument
Dec 29 13:11:59 postino
:59 postino ctl_cyrusdb[2922]: DBERROR: opening
/var/imap/mailboxes.db: Invalid argument
Dec 29 13:11:59 postino ctl_cyrusdb[2922]: DBERROR: opening
/var/imap/mailboxes.db: cyrusdb error
how can I solve this problem ?
cyrus continue to work but I have these errors on master startup
Hi List,
I have a cyrus system with only about 20 users on it. They have about 3
gigs of mail.
The mailboxes.db file is unreadable. of course, reconstruct -m is
unavailable, in typical dougadamsian fashion.
I have seen recommendations to try to 'rebuild the db' using the
'db.backup1
On Aug 25, 2006, at 12:48 PM, !jeff!{InterVerse} wrote:
Hi List,
I have a cyrus system with only about 20 users on it. They have
about 3 gigs of mail.
The mailboxes.db file is unreadable. of course, reconstruct -m is
unavailable, in typical dougadamsian fashion.
I have seen
What error are you getting that indicates that mailboxes.db is
unreadable? I suspect that the backups will also be unreadable, due
to the way they are made. If they *are* readable, as the cyrus user:
ctl_mboxlist -d -f db.backup1/mailboxes.db somefile.txt
You'll want to examine
Wes,
thanks for the response. I still have the problem.
At 01:42 PM 8/25/2006, you wrote:
What error are you getting that indicates that mailboxes.db is
unreadable?
a bunch of places, but here's one:
sudo -u cyrus /usr/local/cyrus/bin/reconstruct -r -f user
fatal error: can't read
mailboxes.db. Minus anything that's
really corrupted -- as opposed to corrupted meta-data.
how do I use reconstruct to regenerate mailboxes.db from the
contents of the cyrus spool area?
Move mailboxes.db and the contents of the db directory out of the
way. Then, for each mailbox (derived either
On May 18, 2006, at 12:11 PM, Andrew Morgan wrote:
On Wed, 17 May 2006, Wesley Craig wrote:
On 17 May 2006, at 14:21, Andrew Morgan wrote:
My most recent test was to rebuild the mupdate master
mailboxes.db from my backend server.
skiplist - 20-25 minutes
berkeley - 3 minutes
How many
On Mon, 22 May 2006, Patrick Radtke wrote:
On May 18, 2006, at 12:11 PM, Andrew Morgan wrote:
On Wed, 17 May 2006, Wesley Craig wrote:
On 17 May 2006, at 14:21, Andrew Morgan wrote:
My most recent test was to rebuild the mupdate master mailboxes.db from
my backend server.
skiplist - 20
mailboxes.db from my backend server.
skiplist - 20-25 minutes
berkeley - 3 minutes
How many mailboxes are there?
About 145000.
Is there also a speed difference when running
'time ctl_mboxlist -mw'
from your backends?
That's what I did. :)
haha, yup:) I should have been clearer.
I want
On Mon, 22 May 2006, Patrick Radtke wrote:
haha, yup:) I should have been clearer.
I want to know the diff speed, not the rebuild speed.
So how long does ctl_mboxlist -mw take to run when the mupdate master is in
sync with the backend.
For example,
with backend and murder master in sync,
I have a patch set to ctl_mboxlist that outputs mailboxes.db on the
backend in a format that may be concatenated and reloaded on the
mupdate master. Using this method, we can rebuild our mupdate master
from the collective backends in a matter of minutes, even with 800K
mailboxes.
:wes
1 - 100 of 201 matches
Mail list logo
