Re: [Dovecot] v2.2.beta2 released
On 26.02.2013, at 21:23, Timo Sirainen wrote: > On 26.2.2013, at 22.20, Michael Grimm wrote: >> Actually, while going through all those files and writing this mail, all >> missing messages appeared in my MUA, and I do find in both maillogs: >> >> @mx1: >> | dovecot: dsync-local(test): Error: dsync([email protected]): I/O has stalled, >> no activity for 600 seconds >> | dovecot: dsync-local(test): Error: Remote command process isn't dying, >> killing it >> >> @mx2: >> | dovecot: dsync-local(test): Error: dsync([email protected]): I/O has stalled, >> no activity for 600 seconds >> | dovecot: dsync-local(test): Error: Remote command process isn't dying, >> killing it > > Ah, this explains the behavior. I had hoped that with the redesign there was > practically no way to cause this kind of I/O stalling. JFTR: Timo was right: this kind of stalling has not been caused by dovecot/replicator/dsync, no it was solely my fault: I had had my firewall configured in such a way that those ssh connections between both servers were by far to limited (rate of new connections over a time interval) for my test scenario. Now, after removing those limitations all mails are synchronized immediately without any more stalling. Sorry for bothering you, Michael
Re: [Dovecot] v2.2.beta2 released
On 26.2.2013, at 22.20, Michael Grimm wrote: > BUT: It look as if I haven't waited long enough for replication to become > finished, sorry :-( > > Actually, while going through all those files and writing this mail, all > missing messages appeared in my MUA, and I do find in both maillogs: > > @mx1: > | dovecot: dsync-local(test): Error: dsync([email protected]): I/O has stalled, > no activity for 600 seconds > | dovecot: dsync-local(test): Error: Remote command process isn't dying, > killing it > > @mx2: > | dovecot: dsync-local(test): Error: dsync([email protected]): I/O has stalled, > no activity for 600 seconds > | dovecot: dsync-local(test): Error: Remote command process isn't dying, > killing it Ah, this explains the behavior. I had hoped that with the redesign there was practically no way to cause this kind of I/O stalling. > Do you have any idea what I should do next? Send me the last rawlogs just before it stalls, from both servers? They should show what each side thought they sent to the other, and what the other really received, and from that I can hopefully find out more easily why it stalled.
Re: [Dovecot] v2.2.beta2 released
On 26.02.2013, at 10:55, Timo Sirainen wrote: > I can't reproduce this. Some interesting questions: > > * If you include hostname+counter in the message, what do the mailboxes look > like in the different sides? Did they skip over some numbers or did they both > stop at some specific remote counter and continue the local counters until > the end? (I am down with my tests to 100 messages injected at mx1 and mx2 simultaneously, and this is with Dovecot v2.2.rc1 (ef7eb84d9a3a)) Both inboxes contain all 100 messages injected at its injection site, meaning all 100 messages injected at mx1 show up at mx1's inbox, and all 100 messages injected at mx2 show up at mx2's inbox. The remaining few messages are those replicated, e.g. 22 injected at mx2 can be found in mx1's inbox, and 23 injected at mx1 can be found in mx2's inbox. Thus, replication stops early. > * Is it even trying to run doveadm sync commands at the end? (e.g. make > dsync_remote_cmd execute some wrapper script that logs something) Wrapper script shows 23 invocations at mx1 and mx2, each. > * If the doveadm syncs continue, try saving rawlogs from them to see what > they're doing (-r /tmp/rawlog parameter to doveadm dsync-server). I do have rawlogs, but I am helpless when it comes to their interpretation, though. :-( Perhaps of importance: | mx1> grep @test /tmp/rawlog | grep I: | wc | 22 881650 | mx1> grep @test /tmp/rawlog | grep O: | wc | 1 4 74 | mx2> grep @test /tmp/rawlog | grep I: | wc | 22 881628 | mx2> grep @test /tmp/rawlog | grep O: | wc | 0 0 0 BUT: It look as if I haven't waited long enough for replication to become finished, sorry :-( Actually, while going through all those files and writing this mail, all missing messages appeared in my MUA, and I do find in both maillogs: @mx1: | dovecot: dsync-local(test): Error: dsync([email protected]): I/O has stalled, no activity for 600 seconds | dovecot: dsync-local(test): Error: Remote command process isn't dying, killing it @mx2: | dovecot: dsync-local(test): Error: dsync([email protected]): I/O has stalled, no activity for 600 seconds | dovecot: dsync-local(test): Error: Remote command process isn't dying, killing it And in rawlog I do now find ... | mx1> grep @test /tmp/rawlog | grep I: | wc | 22 881650 | mx1> grep @test /tmp/rawlog | grep O: | wc | 1 4 74 | mx2> grep @test /tmp/rawlog | grep I: | wc | 99 3967326 | mx2> grep @test /tmp/rawlog | grep O: | wc | 78 3125850 ... thus, all mails became replicated after that 600 seconds timeout. But why do I run into timeouts when those mails become injected second by second, but not, if injected without waiting time? Do you have any idea what I should do next? Regards, Michael
Re: [Dovecot] v2.2.beta2 released
On 2013-02-26 10:55, Timo Sirainen wrote: On 25.2.2013, at 17.38, Michael Grimm wrote: Yes. I would expect 400 messages at every inbox, but normally I do end up with around 270 in an inbox, and both inboxes do show slightly different numbers (e.g. 245 and 297). (Looks like stopping.) I can't reproduce this. Some interesting questions: * If you include hostname+counter in the message, what do the mailboxes look like in the different sides? Did they skip over some numbers or did they both stop at some specific remote counter and continue the local counters until the end? * Is it even trying to run doveadm sync commands at the end? (e.g. make dsync_remote_cmd execute some wrapper script that logs something) * If the doveadm syncs continue, try saving rawlogs from them to see what they're doing (-r /tmp/rawlog parameter to doveadm dsync-server). I will investigate this further, but that will take some time. I did repeat this test appr. 10 times, always the same. Restarting both dovecot servers or running "doveadm dsync -d -l 30 -u test -f" leads to an instantaneous appearence of all 400 messages in every inbox. It probably works even without -f parameter? In the meantime I can confirm that it will work without that parameter as well. Thanks and regards, Michael
Re: [Dovecot] v2.2.beta2 released
On 25.2.2013, at 17.38, Michael Grimm wrote: > On 2013-02-25 15:58, Timo Sirainen wrote: >> On 21.2.2013, at 22.12, Michael Grimm wrote: > >>> Whenever I do run those tests with a delay of 1 second between every >>> injection, I do observe, that not all mails injected become visible in my >>> MUAs (Mail.app and Roundcube), immediately. All "get new mail" >>> functionality or MUA restarts fails to fetch those missing messages from >>> both servers. >> So .. what exactly do you mean by this? That in both servers you run >> a script that delivers a mail once per second to the same user? > > Yes. In my tests I do inject 200 messages at every server simultaneously with > a delay of 1 second. > >> And at some point the replication just stops replicating those mails >> to the other server? > > Yes. I would expect 400 messages at every inbox, but normally I do end up > with around 270 in an inbox, and both inboxes do show slightly different > numbers (e.g. 245 and 297). (Looks like stopping.) I can't reproduce this. Some interesting questions: * If you include hostname+counter in the message, what do the mailboxes look like in the different sides? Did they skip over some numbers or did they both stop at some specific remote counter and continue the local counters until the end? * Is it even trying to run doveadm sync commands at the end? (e.g. make dsync_remote_cmd execute some wrapper script that logs something) * If the doveadm syncs continue, try saving rawlogs from them to see what they're doing (-r /tmp/rawlog parameter to doveadm dsync-server). > I did repeat this test appr. 10 times, always the same. Restarting both > dovecot servers or running "doveadm dsync -d -l 30 -u test -f" leads to an > instantaneous appearence of all 400 messages in every inbox. It probably works even without -f parameter?
Re: [Dovecot] v2.2.beta2 released
On 2013-02-25 15:58, Timo Sirainen wrote: On 21.2.2013, at 22.12, Michael Grimm wrote: Whenever I do run those tests with a delay of 1 second between every injection, I do observe, that not all mails injected become visible in my MUAs (Mail.app and Roundcube), immediately. All "get new mail" functionality or MUA restarts fails to fetch those missing messages from both servers. So .. what exactly do you mean by this? That in both servers you run a script that delivers a mail once per second to the same user? Yes. In my tests I do inject 200 messages at every server simultaneously with a delay of 1 second. And at some point the replication just stops replicating those mails to the other server? Yes. I would expect 400 messages at every inbox, but normally I do end up with around 270 in an inbox, and both inboxes do show slightly different numbers (e.g. 245 and 297). (Looks like stopping.) I can see how that would happen with regular "doveadm sync" command, but replicator uses stateful syncing where that shouldn't be possible. I did repeat this test appr. 10 times, always the same. Restarting both dovecot servers or running "doveadm dsync -d -l 30 -u test -f" leads to an instantaneous appearence of all 400 messages in every inbox. What is puzzeling me most: If I do inject both 200 messages *without* any delay, I cannot see this behavior. All 400 messages appear without delay. Regards, Michael
Re: [Dovecot] v2.2.beta2 released
On 21.2.2013, at 22.12, Michael Grimm wrote: > Whenever I do run those tests with a delay of 1 second between every > injection, I do observe, that not all mails injected become visible in my > MUAs (Mail.app and Roundcube), immediately. All "get new mail" functionality > or MUA restarts fails to fetch those missing messages from both servers. So .. what exactly do you mean by this? That in both servers you run a script that delivers a mail once per second to the same user? And at some point the replication just stops replicating those mails to the other server? I can see how that would happen with regular "doveadm sync" command, but replicator uses stateful syncing where that shouldn't be possible.
Re: [Dovecot] v2.2.beta2 released
Thank you very much Michael.
I'll set it up again, because I think that initially I was not using any
aggregator service. My setup is a little atypical as I have servers
spread-out on 2 (soon 3) continents that are connected via slow uplinks.
Hopefully the v2.2 is more stable and less buggy for the synch ;)
Best regards,
Andrei
> Hi --
>
> On 2013-02-21 Michescu Andrei wrote:
>
>> Can you post to the list your working configurations for dovecot?
>
>
> (This is based on
> http://dovecot.org/list/dovecot/2012-March/064513.html)
>
> My design:
>
> single user "vmail" to run dsync over ssh
> (one may use root instead)
>
>
> Thus, my prerequisites are:
>
> create "vmail" user accounts at both servers (example: mx1 and
> mx2)
> exchange ssh-keys for ssh authentication between both servers
> involved
>
>
> My relevant parts from dovecot.conf, identical for both servers:
>
> ## --- DSYNC REPLICATION
>
>
> # ssh command line used in dsync replication
> # added:
> # -p xxx (ssh port)
> # -o mail_plugins=(omit mail_log plugins for
> dsync)
> #
> dsync_remote_cmd = ssh -p 44488 -l%{login} %{host} doveadm
> -omail_plugins= dsync-server -u%u -n%{namespace}
>
> # aggregator, replicator, doveadm, and config needed, and
> dsync_remote_cmd (see above)
> #
> service aggregator {
> # give enough permissions for mail processes
> #
> fifo_listener replication-notify-fifo {
> user = vmail
> mode = 0600
> }
> unix_listener replication-notify {
> user = vmail
> mode = 0600
> }
> }
> service replicator {
> # start replication at startup
> #
> process_min_avail = 1
> }
> service doveadm {
> # if you're using a single virtual user, set this to
> start ssh as vmail (not root)
> #
> user = vmail
> }
> service config {
> # needed to grant access to /var/run/dovecot/config for
> service doveadm
> #
> unix_listener config {
> user = vmail
> }
> }
>
>
>
> The following part is for server mx1, only:
> ---
>
> # dsync replication plugin
> #
> plugin {
> # this host replicates to remote host
> #
> mail_replica = remote:[email protected]
>
> # run full synchronization mode every other hour
> #
> replication_full_sync_interval = 1 hours
> }
>
>
> The following part is for server mx2, only:
> ---
>
> # dsync replication plugin
> #
> plugin {
> # this host replicates to remote host
> #
> mail_replica = remote:[email protected]
>
> # run full synchronization mode every other hour
> #
> replication_full_sync_interval = 1 hours
> }
>
> HTH,
> Michael
>
>
> !DSPAM:51271e3f42781904211018!
>
>
Re: [Dovecot] v2.2.beta2 released
Il 21/02/2013 16:34, Timo Sirainen ha scritto: Please test and report any bugs found! Hi, I'm running dovecot 2.2b2 , for the first time, with vpopmail-auth and works fine. But I found this bug, also present in 2.1.15. When I enable dict quota with mysql and in dovecot DB there is no entry for the user, dovecot waits 3 minutes and 30 seconds before create the entry and close telnet session: Feb 22 11:45:26 demo-vpop dovecot: pop3-login: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=18132, secured, session=<6R6m403WlAB/AAAB> Feb 22 11:45:32 demo-vpop dovecot: pop3([email protected]): Disconnected: Logged out top=0/0, retr=0/0, del=1/21, size=9828 Feb 22 11:45:32 demo-vpop dovecot: dict: mysql(localhost): Connected to database dovecot Feb 22 11:46:02 demo-vpop dovecot: pop3([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds Feb 22 11:46:32 demo-vpop dovecot: pop3([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds Feb 22 11:47:02 demo-vpop dovecot: pop3([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds Feb 22 11:47:32 demo-vpop dovecot: pop3([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds Feb 22 11:48:02 demo-vpop dovecot: pop3([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds Feb 22 11:48:32 demo-vpop dovecot: pop3([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds Feb 22 11:49:02 demo-vpop dovecot: pop3([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds # telnet 0 110 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. +OK Dovecot ready. user [email protected] +OK pass ciao +OK Logged in. [...] 21 468 . dele 21 +OK Marked to be deleted. quit +OK Logging out, messages deleted. [ here is waiting for logout 3 minutes] Connection closed by foreign host. LDA as the same problem: Feb 22 12:09:00 demo-vpop dovecot: master: Dovecot v2.2.beta2 starting up (core dumps disabled) Feb 22 12:09:02 demo-vpop dovecot: lda([email protected]): msgid=<[email protected]>: saved mail to INBOX Feb 22 12:09:02 demo-vpop dovecot: dict: mysql(localhost): Connected to database dovecot Feb 22 12:09:32 demo-vpop dovecot: lda([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds Feb 22 12:10:02 demo-vpop dovecot: lda([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 seconds Feb 22 12:10:32 demo-vpop dovecot: lda([email protected]): Error: read(/usr/local/dovecot-2.2/var/run/dovecot/dict) failed: Timeout after 30 second Here is my configuration: # dovecot -n # 2.2.beta2: /usr/local/dovecot-2.2/etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.6 default_login_user = dovecot dict { quota = mysql:/usr/local/dovecot-2.2/etc/dovecot/dovecot-dict-sql.conf.ext } first_valid_gid = 89 first_valid_uid = 89 last_valid_gid = 89 last_valid_uid = 89 mail_location = maildir:~/Maildir mail_plugins = quota managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = vpopmail } plugin { quota = maildir:User quota quota2 = dict:User dict::proxy::quota sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } service auth { unix_listener auth-userdb { group = vchkpw mode = 0660 user = vpopmail } } service dict { unix_listener dict { group = vchkpw mode = 0600 user = vpopmail } } ssl_cert = http://www.linux.it/~alessice/ on LinkedIn -> http://www.linkedin.com/in/alessice Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz/ @ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it
Re: [Dovecot] v2.2.beta2 released
Hi --
On 2013-02-21 Michescu Andrei wrote:
Can you post to the list your working configurations for dovecot?
(This is based on
http://dovecot.org/list/dovecot/2012-March/064513.html)
My design:
single user "vmail" to run dsync over ssh
(one may use root instead)
Thus, my prerequisites are:
create "vmail" user accounts at both servers (example: mx1 and
mx2)
exchange ssh-keys for ssh authentication between both servers
involved
My relevant parts from dovecot.conf, identical for both servers:
## --- DSYNC REPLICATION
# ssh command line used in dsync replication
# added:
# -p xxx (ssh port)
# -o mail_plugins=(omit mail_log plugins for
dsync)
#
dsync_remote_cmd = ssh -p 44488 -l%{login} %{host} doveadm
-omail_plugins= dsync-server -u%u -n%{namespace}
# aggregator, replicator, doveadm, and config needed, and
dsync_remote_cmd (see above)
#
service aggregator {
# give enough permissions for mail processes
#
fifo_listener replication-notify-fifo {
user = vmail
mode = 0600
}
unix_listener replication-notify {
user = vmail
mode = 0600
}
}
service replicator {
# start replication at startup
#
process_min_avail = 1
}
service doveadm {
# if you're using a single virtual user, set this to
start ssh as vmail (not root)
#
user = vmail
}
service config {
# needed to grant access to /var/run/dovecot/config for
service doveadm
#
unix_listener config {
user = vmail
}
}
The following part is for server mx1, only:
---
# dsync replication plugin
#
plugin {
# this host replicates to remote host
#
mail_replica = remote:[email protected]
# run full synchronization mode every other hour
#
replication_full_sync_interval = 1 hours
}
The following part is for server mx2, only:
---
# dsync replication plugin
#
plugin {
# this host replicates to remote host
#
mail_replica = remote:[email protected]
# run full synchronization mode every other hour
#
replication_full_sync_interval = 1 hours
}
HTH,
Michael
Re: [Dovecot] v2.2.beta2 released
On 2/21/2013 8:43 AM, Odhiambo Washington wrote: > I've been running 2.2beta1 in production since it got out and I haven't had > any issues. However, my setup is simply IMAP/POP3 without any complicated > configurations. This is on FreeBSD 8.3-STABLE with about 100 users. > I've just updated to 2.2b2... The same applies to me except it's CentOS 5 and I have only a half dozen POP3 users and a couple of IMAP users with a total of about 2 dozen mailboxes. No problems with 2.2beta2 so far. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan
Re: [Dovecot] v2.2.beta2 released
Hello Michael, Can you post to the list your working configurations for dovecot? I've been fighting with the dsync replication a while ago and was super buggy so I've put that project on ice. If now it finally works I would like to get it moving again. Best, Andrei > On 21.02.2013, at 21:17, Timo Sirainen wrote: >> On 21.2.2013, at 22.12, Michael Grimm wrote: > > >>> But, if I do restart any one of both dovecot servers involved, those >>> remaining missing messages are fetched instantaneously. >> >> Possibly a bug, see if it still happens with beta2. > > Sorry, I did forget to mention that this is happening with v2.2.beta2 > (3fb9a8bc35aa) as well. > >>> Thus, if I am not mistaken that something like a "flushing" really >>> takes place, I wonder if there is a "doveadm flush replicator-queue" >>> functionality is available already (that I might have over-seen), and >>> if not, would that be a big deal to implement? >> >> Well, you can sync a user with e.g.: doveadm sync -d -l 30 -u >> user@domain >> or with -A parameter to sync everyone. And with -f parameter to do a >> full sync if needed. > > I needed to add that "-f" for full sync, and that "flushed" the queue. > Thanks for pointing me to that. > > I do have a "replication_full_sync_interval = 1 hours" set. Does that > setting equals to the same like running a "doveadm dsync ..." every other > hour? > > Regards, Michael > !DSPAM:512687b9301841449136444! > >
Re: [Dovecot] v2.2.beta2 released
On 21.02.2013, at 21:17, Timo Sirainen wrote: > On 21.2.2013, at 22.12, Michael Grimm wrote: >> But, if I do restart any one of both dovecot servers involved, those >> remaining missing messages are fetched instantaneously. > > Possibly a bug, see if it still happens with beta2. Sorry, I did forget to mention that this is happening with v2.2.beta2 (3fb9a8bc35aa) as well. >> Thus, if I am not mistaken that something like a "flushing" really takes >> place, I wonder if there is a "doveadm flush replicator-queue" functionality >> is available already (that I might have over-seen), and if not, would that >> be a big deal to implement? > > Well, you can sync a user with e.g.: doveadm sync -d -l 30 -u user@domain > or with -A parameter to sync everyone. And with -f parameter to do a full > sync if needed. I needed to add that "-f" for full sync, and that "flushed" the queue. Thanks for pointing me to that. I do have a "replication_full_sync_interval = 1 hours" set. Does that setting equals to the same like running a "doveadm dsync ..." every other hour? Regards, Michael
Re: [Dovecot] v2.2.beta2 released
On 21.2.2013, at 22.12, Michael Grimm wrote: > I am running v2.2beta1 for almost a week now (handful of users, ~1000 > mails/day). And yes, I can confirm that replication works ... > >> Please test and report any bugs found! > > ... there is only a "feature request" left: > > I did run a lot of stress tests as mentioned before (simultaneously injected > local mail). > > Whenever I do run those tests with a delay of 1 second between every > injection, I do observe, that not all mails injected become visible in my > MUAs (Mail.app and Roundcube), immediately. All "get new mail" functionality > or MUA restarts fails to fetch those missing messages from both servers. > > But, if I do restart any one of both dovecot servers involved, those > remaining missing messages are fetched instantaneously. It seems to me, as if > those missing messages were kept in the "replicator queue" and not delivered > to the partner server, and as if that queue became flushed during restart. > After restart all injected and replicated messages are accessible by the > MUAs. Possibly a bug, see if it still happens with beta2. > I never waited longer then 10 minutes before restarting dovecot, thus I do > not know if I didn't wait long enough. But I can say that an additionally > injected local mail shows up in both MUAs but doesn't become replicated. > > Thus, if I am not mistaken that something like a "flushing" really takes > place, I wonder if there is a "doveadm flush replicator-queue" functionality > is available already (that I might have over-seen), and if not, would that be > a big deal to implement? Well, you can sync a user with e.g.: doveadm sync -d -l 30 -u user@domain or with -A parameter to sync everyone. And with -f parameter to do a full sync if needed. The -l 30 parameter adds locking so two dsyncs won't run at the same time for the user.
Re: [Dovecot] v2.2.beta2 released
On 21.02.2013, at 16:34, Timo Sirainen wrote: > A ton of fixes since beta1. Especially the new dsync and the replication > server related to that should really work now. I am running v2.2beta1 for almost a week now (handful of users, ~1000 mails/day). And yes, I can confirm that replication works ... > Please test and report any bugs found! ... there is only a "feature request" left: I did run a lot of stress tests as mentioned before (simultaneously injected local mail). Whenever I do run those tests with a delay of 1 second between every injection, I do observe, that not all mails injected become visible in my MUAs (Mail.app and Roundcube), immediately. All "get new mail" functionality or MUA restarts fails to fetch those missing messages from both servers. But, if I do restart any one of both dovecot servers involved, those remaining missing messages are fetched instantaneously. It seems to me, as if those missing messages were kept in the "replicator queue" and not delivered to the partner server, and as if that queue became flushed during restart. After restart all injected and replicated messages are accessible by the MUAs. I never waited longer then 10 minutes before restarting dovecot, thus I do not know if I didn't wait long enough. But I can say that an additionally injected local mail shows up in both MUAs but doesn't become replicated. Thus, if I am not mistaken that something like a "flushing" really takes place, I wonder if there is a "doveadm flush replicator-queue" functionality is available already (that I might have over-seen), and if not, would that be a big deal to implement? JFTR and with kind regards, Michael
Re: [Dovecot] v2.2.beta2 released
I've been running 2.2beta1 in production since it got out and I haven't had any issues. However, my setup is simply IMAP/POP3 without any complicated configurations. This is on FreeBSD 8.3-STABLE with about 100 users. I've just updated to 2.2b2... On 21 February 2013 18:34, Timo Sirainen wrote: > http://dovecot.org/releases/2.2/beta/dovecot-2.2.beta2.tar.gz > http://dovecot.org/releases/2.2/beta/dovecot-2.2.beta2.tar.gz.sig > > A ton of fixes since beta1. Especially the new dsync and the replication > server related to that should really work now. It also works correctly now > for shared mailboxes with private \Seen flags. And the replication server > uses incremental syncing after the initial full sync, so it should be > pretty efficient also. > > I've only two things left to do before v2.2.rc1: > > 1. Implement dsync to work via TCP and TCP+SSL sockets. This is pretty > easy to do actually, since it can use the existing doveadm-server to start > up. > > 2. Read up all the pending mails from Dovecot mailing list and fix up the > reported issues. Actually I guess most of those are for v2.1, but still I > should get around to it. :) > > There shouldn't be any major bugs left, so I'm expecting v2.2.rc1 out in > maybe a week or so, hopefully followed by the final v2.2.0 soon afterwards. > Please test and report any bugs found! > > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler.
