On Sun, Dec 05, 2010 at 10:27:27AM +1030, Stephen Carr wrote:
> Dear All
>
> My prior idea was incorrect
>
> I just got this see below
>
> There was nothing reported by fuser in the users INBOX.
>
> So I ran reconstrust -f -r -G on both client and replica as per
> Bron's idea.
>
> Did a sync_
Dear All
My prior idea was incorrect
I just got this see below
There was nothing reported by fuser in the users INBOX.
So I ran reconstrust -f -r -G on both client and replica as per Bron's
idea.
Did a sync_client -v -l -m user.USER was OK
The started a rolling sync_client - seems OK
Shou
Dear All
I ran fuser * on the mailbox of the user that had the problem and got
cyrus.cache: 11366 11366m
cyrus.header: 2487 11366
cyrus.index: 2487 2487m 11366 11366
The processes are imapd
I killed the imapd processes and it seems OK.
The clients are using Thunderbir
On Sun, Dec 05, 2010 at 07:44:08AM +1030, Stephen Carr wrote:
> Dear All
>
> I thought the upgrade had worked but after more than 10 hours the
> following type of error were reported. This is from a short manual
> run of sync_client.
Can you try running a reconstruct -G of that user at each end?
On Sat, Dec 04, 2010 at 10:33:49AM -0500, Chris Conn wrote:
> Hello,
>
> I am looking at this option for 2.4.5;
>
> disconnect_on_vanished_mailbox: 1
>
> If enabled, IMAP/POP3/NNTP clients will be disconnected by the server if
> the currently selected mailbox is (re)moved by another session.
>
Dear All
I thought the upgrade had worked but after more than 10 hours the
following type of error were reported. This is from a short manual run
of sync_client.
Dec 5 07:20:40 brooks sync_client[31978]: MAILBOX received NO response:
System I/O error
Dec 5 07:20:40 brooks sync_client[319
Hello,
I am looking at this option for 2.4.5;
disconnect_on_vanished_mailbox: 1
If enabled, IMAP/POP3/NNTP clients will be disconnected by the server if
the currently selected mailbox is (re)moved by another session.
Otherwise, the missing mailbox is treated as empty while in use by the
clien
On Sat, Dec 04, 2010 at 07:37:50PM +1030, Stephen G Carr wrote:
> Dear Bron
>
> After about 3 hours the messages stopped.
Great.
> I notice a massive change in db_stat -c when comparing 2.3.16 to
> 2.4.5 the earlier version seemed to hold locks for ages for example
> the number of current would
Dear Bron
After about 3 hours the messages stopped.
I notice a massive change in db_stat -c when comparing 2.3.16 to 2.4.5
the earlier version seemed to hold locks for ages for example the number
of current would be about 40+ depending on concurrent connections now
it is Zero
Thanks to ALL
On Sat, Dec 04, 2010 at 03:10:30PM +1030, Stephen Carr wrote:
> Dear All
>
> I disabled -v -l from my sync_client options so the logs would not blow
> out - one was 20MB in no time.
Cool :)
> Replication is working as I checked an email on being delivered to the
> master was on the replica in
On Sat, Dec 04, 2010 at 01:59:33PM +1030, Stephen Carr wrote:
> Dear All
>
> I had a problem last week upgrading 2.3.16 to 2.4.4 due to a CRC bug.
>
> I have now updated from 2.3.16 to 2.4.5 with no major problems but I am
> getting a massive number of records of the type below - I will have to
11 matches
Mail list logo
