Re: mailboxes.db disagree between master and replica

Quoting Tod Pike : Hello: I am running a 3.X cyrus setup with master/slave replication. I have discovered that one of my replicas has gotten out of sync with it's master server, not in the sense that the mailboxes are not replicated, but that the mailboxes live in different partitions on the

Re: Re: mailboxes.db locking problem after updating from 2.4 to 2.5.9

Well, I did another try to move to 2.5 branch. I make some preparation this time: 1. took 2.5.10 and put twoskip & skiplist patches from master [PATCH] cyrusdb: add "CYRUSDB_NOCOMPACT" open flag to avoid [PATCH] twoskip: release the readlock in foreach every 256 misses 2. put mailboxes.db to /dev/

Re: mailboxes.db locking problem after updating from 2.4 to 2.5.9

On 18/11/16 01:07, Bron Gondwana via Info-cyrus wrote: > On Fri, 18 Nov 2016, at 10:51, Wolfgang Breyha via Info-cyrus wrote: >> I already filed a bug https://github.com/cyrusimap/cyrus-imapd/issues/43 >> but no response so far. I directly asked Bron, but no response as well. > > Sorry, I really

Re: mailboxes.db locking problem after updating from 2.4 to 2.5.9

On Fri, 18 Nov 2016, at 10:51, Wolfgang Breyha via Info-cyrus wrote: > On 17/11/16 14:00, Deniss via Info-cyrus wrote: > > Any ideas or suggestion for investigation ? > > I already filed a bug > https://github.com/cyrusimap/cyrus-imapd/issues/43 > but no response so far. I directly asked Bron, but

Re: mailboxes.db locking problem after updating from 2.4 to 2.5.9

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 fine until morning when a count of s

Re: mailboxes.db locking problem after updating from 2.4 to 2.5.9

Did you run reconstruct like the upgrade documentation recommends? When I did my upgrade, from 2.4.x to 2.5 that's about all I had to do. I don't recall having to run ctl_mboxlist -du https://www.cyrusimap.org/docs/cyrus-imapd/2.5.0/install-upgrade.php http://www.cyrusimap.org/~vanmeeuwen/imap/

Re: mailboxes.db invalid entries

The tool is safe to use with Cyrus running Of course if you delete a mailboxes db entry without deleting the underlying files and then recreate the folder, things can get confused because there are already files on disk... Bron On Sat, Apr 23, 2016, at 06:58, Jan Kowalsky via Info-cyrus wrote:

Re: mailboxes.db invalid entries

Hi all, Am 22.04.2016 um 22:28 schrieb Jan Kowalsky: > Hi Wolfgang, > > thanks for your answer. > > Am 22.04.2016 um 11:06 schrieb Wolfgang Breyha: >> Jan Kowalsky via Info-cyrus wrote on 22/04/16 01:28: >>> First I tried to dump the mailbox.db with ctl_mboxlist -d /tmp/mailboxes.txt >>> >>> Aft

Re: mailboxes.db invalid entries

Hi Wolfgang, thanks for your answer. Am 22.04.2016 um 11:06 schrieb Wolfgang Breyha: > Jan Kowalsky via Info-cyrus wrote on 22/04/16 01:28: >> 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

Re: mailboxes.db invalid entries

Jan Kowalsky via Info-cyrus wrote on 22/04/16 01:28: > 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 > stopped cyrus. Have

Re: mailboxes.db invalid entries

Ouch, yeah - spaces in group names? That's gotta be bogus. I'm surprised we accept those in the first place. I guess the code should probably check that keys are valid identifiers though :( So that is a legitimate bug. Bron. On Fri, Apr 22, 2016, at 09:28, Jan Kowalsky via Info-cyrus wrote

Re: mailboxes.db discrepancies between mailbox and mupdate servers

> According to my notes, MUPDATEPUSH is used through an admin user's IMAP > connection (via imtest) not through mupdatetest. > > If the mailbox doesn't actually exist, you might need to use LOCALCREATE via > IMAP to the backend prior to MUPDATEPUSH. > > LC1 LOCALCREATE user.foo Thank you Simon

Re: mailboxes.db discrepancies between mailbox and mupdate servers

On 9 Jul 2013, at 22:20, Shawn Winnington-Ball 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 >> are in, you

Re: mailboxes.db discrepancies between mailbox and mupdate servers

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

Re: mailboxes.db discrepancies between mailbox and mupdate servers

On 7/9/13 3:04 PM, "Shawn Winnington-Ball" wrote: >Hi all, > >I'm having an issue with a Cyrus murder wherein the mupdate server >believes that a set of mailboxes are in mid-transfer, when in fact >they don't exist on any of the downstream mailbox servers. Here's >an example of a lone entry glea

Re: mailboxes.db inconsistency caused by simultaneous renames

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 : > Hmf, I should've read the release notes first :( It's fixed in 2.4.17: > > "Fixed bug #3696: can n

Re: mailboxes.db inconsistency caused by simultaneous renames

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:

Re: mailboxes.db vs IMAP client irregularities

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 lot

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 1:28 PM, Bron Gondwana wrote: > On Sat, May 19, 2012 at 12:56:44PM -0700, Stephen Ingram wrote: >> Wow, thanks! I didn't know about that command. It exposed them! >> Strange, they were in /var/spool/imap/u/DELETED/ (my mailbox root is >> /var/spool/imap). I'm not sure why t

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 1:00 PM, Simon Matter wrote: >> On 05/19/2012 01:51 PM, Stephen Ingram wrote: >>> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had >>> an issue with a folder in a mailbox that would not show any >>> subfolders. I created a new folder 'folder2' and moved

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 12:56:44PM -0700, Stephen Ingram wrote: > Wow, thanks! I didn't know about that command. It exposed them! > Strange, they were in /var/spool/imap/u/DELETED/ (my mailbox root is > /var/spool/imap). I'm not sure why they wouldn't be in > /var/spool/imap/j/user/jmaxwell (jmaxwe

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012, at 11:53 AM, Stephen Ingram wrote: > On Sat, May 19, 2012 at 10:59 AM, Bron Gondwana wrote: > > 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

Re: mailboxes.db vs IMAP client irregularities

> On 05/19/2012 01:51 PM, Stephen Ingram wrote: >> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had >> an issue with a folder in a mailbox that would not show any >> subfolders. I created a new folder 'folder2' and moved all of the >> subfolders to it and then performed a recon

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 12:40 PM, Patrick Boutilier wrote: > On 05/19/2012 04:02 PM, Stephen Ingram wrote: >> >> On Sat, May 19, 2012 at 10:58 AM, Patrick Boutilier >>  wrote: >>> >>> On 05/19/2012 01:51 PM, Stephen Ingram wrote: I'm running 2.4.13 from the invoca rpms on CentOS 5.

Re: mailboxes.db vs IMAP client irregularities

On 05/19/2012 04:02 PM, Stephen Ingram wrote: On Sat, May 19, 2012 at 10:58 AM, Patrick Boutilier wrote: On 05/19/2012 01:51 PM, Stephen Ingram wrote: I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had an issue with a folder in a mailbox that would not show any subfolders.

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 10:58 AM, Patrick Boutilier wrote: > On 05/19/2012 01:51 PM, Stephen Ingram wrote: >> >> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had >> an issue with a folder in a mailbox that would not show any >> subfolders. I created a new folder 'folder2' and

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 10:59 AM, Bron Gondwana wrote: > 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

Re: mailboxes.db vs IMAP client irregularities

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 if >

Re: mailboxes.db vs IMAP client irregularities

On 05/19/2012 01:51 PM, Stephen Ingram wrote: I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had an issue with a folder in a mailbox that would not show any subfolders. I created a new folder 'folder2' and moved all of the subfolders to it and then performed a reconstruct on th

Re: mailboxes.db problem

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 WCP

Re: mailboxes.db problem

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 runni

Re: mailboxes.db problem

OS is FreeBSD 5.5-STABLE cyrus-imapd 2.2.12 installed this problem started accouring after a RAID5 reconstruction. cyrus was installed using ports collection thanks Rick On Sat, 30 Dec 2006, Andreas Winkelmann wrote: On Friday 29 December 2006 15:21, RJ45 wrote: Dec 29 13:11:59 postino

Re: mailboxes.db problem

On Friday 29 December 2006 15:21, RJ45 wrote: > Dec 29 13:11:59 postino ctl_cyrusdb[2922]: DBERROR db3: log_flush: LSN > past current end-of-log > Dec 29 13:11:59 postino ctl_cyrusdb[2922]: DBERROR db3: log_flush: LSN > past current end-of-log > Dec 29 13:11:59 postino ctl_cyrusdb[2922]: DBERROR d

Re: mailboxes.db unreadable, recovery procedure?

On 25 Aug 2006, at 15:53, !jeff!{InterVerse} wrote: sudo -u cyrus /usr/local/cyrus/bin/reconstruct -r -f user fatal error: can't read mailboxes file OK, so that doesn't work. Now what can I do? If you need a list of mailboxes, you can probably get a pretty complete one with "strings mailbox

Re: mailboxes.db unreadable, recovery procedure?

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

Re: mailboxes.db unreadable, recovery procedure?

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 "

Re: mailboxes.db unreadable, recovery procedure?

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 recommend

Re: mailboxes.db backend comparison

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

Re: mailboxes.db backend comparison

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, ct

Re: mailboxes.db backend comparison

On May 22, 2006, at 1:55 PM, Andrew Morgan wrote: 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 m

Re: mailboxes.db backend comparison

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-25

Re: mailboxes.db backend comparison

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 m

Re: mailboxes.db backend comparison

On 18 May 2006, at 12:11, 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 long does it ta

Re: mailboxes.db backend comparison

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 long does it take to LIST the contents of each database? I d

Re: mailboxes.db backend comparison

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 long does it take to LIST the contents of each database? :wes Cyrus Home Page: http://asg.web.cmu.

Re: mailboxes.db insists on using Berkeley ??

> On Sat, 2004-08-14 at 13:21, J. W.Andersen, Falster System Teknik wrote: >> Ever since cyrus 2.0 I dragged along the mailboxes.db in berkeley >> format, but finally decided to change to skiplist. >> I converted mailboxes.db to skiplist format, and changed imapd.conf >> entry mboxlist_db from berk

Re: mailboxes.db insists on using Berkeley ??

On Sat, 2004-08-14 at 13:21, J. W.Andersen, Falster System Teknik wrote: > Ever since cyrus 2.0 I dragged along the mailboxes.db in berkeley > format, but finally decided to change to skiplist. > I converted mailboxes.db to skiplist format, and changed imapd.conf > entry mboxlist_db from berkele

Re: mailboxes.db: cyrusdb error

On Sat, 2004-03-13 at 03:53, Florin Andrei wrote: > To my utter dismay, none of the typical recovery procedures worked. I > tried these things: > > /usr/lib/cyrus-imapd/ctl_mboxlist -d -f /var/lib/imap/mailboxes.db > > (said it cannot read mailboxes.db) > > /usr/lib/cyrus-imapd/reconstruct -m >

Re: mailboxes.db?

mailboxes.db is the list of all existing mailboxes and folders in cyrus.. it is initially empty and as you create accounts and folders on the mails server it is populated with the names of the folders and the permissions assigned to them.. you can use the ctl_mboxlist program included with cyrus

Re: mailboxes.db problem cont.

On Thu, 11 Dec 2003, Craig Ringer wrote: > Naturally this would need to be prefaced with a warning about the loss > of ACL information - a "use as a last resort only" warning. The ACL information is maintained in the cyrus.header file. If you still have that, there is no reason you should suffer

Re: mailboxes.db problem cont.

Hi I was wondering ... does anybody mind if I add this script to the Wiki? I recently created an entry about the non-working 'reconstruct -m' command (http://asg.web.cmu.edu/twiki/bin/view/Cyrus/ReconstructMailboxes), and it'd be nice to offer /some/ recovery option for people who've been bit

Re: mailboxes.db problem cont.

Many thanks to Scott Adkins and Joe Hrbek for all of their help. Here are a couple of scripts that I wrote to rebuild the mailboxes.db. The scripts do not take into account default domain, basic or no directory hashing, multiple partitions, and possibly other things, but I figured they might give

Re: mailboxes.db problem cont.

It was indeed the tab at the end of each line that caused the problem. I added the tab to the end of each line and implemented it about 3 PM Saturday afternoon and brought the server back on line. On Sun, 2003-09-28 at 12:14, Rob Siemborski wrote: > On Sat, 27 Sep 2003, Hank Beatty wrote: > > > T

Re: mailboxes.db problem cont.

On Sat, 27 Sep 2003, Hank Beatty wrote: > Took dir.txt and converted it to the format of mboxlist file (except for > the tab on the end of each line. Not sure if this caused a problem) This will likely cause a problem with the ACLs. > The above steps got POP working, but IMAP gives ???Mailbox do

Re: mailboxes.db DBERROR's?

Amos Gouaux wrote: > > > On Thu, 28 Jun 2001 07:46:51 -0700, > > Derek Spencer <[EMAIL PROTECTED]> (ds) writes: > > ds> Ok, to be more exact: > ds> Solaris 7 (sparc) > ds> cyrus 2.0.14 > ds> cyrus-sasl 1.5.24 > ds> Berkeley DB 3.2.9 > ds> Postfix 20010228-pl03 > > I don't know if it wou

Re: mailboxes.db DBERROR's?

> On Thu, 28 Jun 2001 07:46:51 -0700, > Derek Spencer <[EMAIL PROTECTED]> (ds) writes: ds> Ok, to be more exact: ds> Solaris 7 (sparc) ds> cyrus 2.0.14 ds> cyrus-sasl 1.5.24 ds> Berkeley DB 3.2.9 ds> Postfix 20010228-pl03 I don't know if it would help or not, but you do have this box ful

Re: mailboxes.db DBERROR's?

Ok, to be more exact: Solaris 7 (sparc) cyrus 2.0.14 cyrus-sasl 1.5.24 Berkeley DB 3.2.9 Postfix 20010228-pl03 I have about 120 users on the system, half of them IMAP, the other half POP. I've found a way to "restore" mailboxes.db. I take a copy that hasn't been corrupted, copy it over to /var

Re: mailboxes.db DBERROR's?

You might provide the list with additional info, like what platform/os you're using. And how many users are we talking about, anyway? What version of db are you using? -Amos On Wed, 27 Jun 2001, derek spencer wrote: > I'm running cyrus 2.0.14 on a machine that's been working fine for about 4

Re: mailboxes.db

From: "jean-marc delpech" <[EMAIL PROTECTED]> > Thanks, Scot it works well now (I forget to say I installed Cyrus 2.0.11) > In the new doc. I read that "crash in reconstruct now fixed" but when I try > to do > cyrus>reconstrution -m > recontructing mailboxes.db currently not supported. > What is t

[info-cyrus] Re: mailboxes.db

ween your way and this way ? Thks/Jean-Marc - Original Message - From: Scot W. Hetzel <[EMAIL PROTECTED]> To: jean-marc delpech <[EMAIL PROTECTED]>; Cyrus Info Mailingliste <[EMAIL PROTECTED]> Sent: Friday, February 02, 2001 3:55 PM Subject: Re: mailboxes.db > From: &qu

Re: mailboxes.db

From: "jean-marc delpech" <[EMAIL PROTECTED]> > how can I recreate the /var/imap/mailboxes.db ? > I know I can recover the databases after a crash but if > I would like to recreate it, is it possible. > In fact the pb is that some body create a folder with cyradm, > but after somebody else delete