replication fails after 2.3.9 -> 2.3.11

[Simon Matter]

> Hi,
>
> Paul Dekkers wrote:
>
>> I finally found a moment for upgrading my 2.3.9 install (using Simon's
>> RPMs on Red Hat 4.6, 64-bit) to 2.3.11-3 (leaving the config files
>> untouched), after which it seems that replication isn't working properly
>> anymore.
>
> While it seems to be only replication for now that fails me; is it
> possible to revert to the previous version? (While that implies for me
> that I'll have to rpm -e and install the previous rpm, I suppose.)
> Not sure if I'd like that, but I really really liked my replication
> running.

You could do that with "rpm -Uvh --oldpackage ...".

>
>> If I run the sync_client, just a simple -u paul, I see in my logs:
>>
>> sync_client[18493]: SETMODSEQ received BAD response: Syntax error in
>> Setflags: Invalid modseq
>> sync_client[18493]: Error in do_user(paul): bailing out!
>>
>> Before the upgrade, I'm sure replication was working properly. I
>> checked, both servers are really running the same versions of
>> everything.
>>
>> I noticed that if I strace the sync_client, the folder on which it bails
>> out is always the same. If I reconstruct that folder, and re-run (or
>> just the mailbox), the process continues (up to the next folder that
>> causes the thing to bail out - although it doesn't bail out on every
>> folder).
>>
>> There were more strange log-items related to the sync_client;
>>
>> sync_client[18232]: USER: Invalid type 1 response from server
>> sync_client[18232]: Discarding: 0000000000000000000000000000000000000000
>> ()
>> sync_client[18232]: Discarding: 2 0
>> 0000000000000000000000000000000000000000 ()
>> sync_client[18232]: Discarding: 3 0
>> 0000000000000000000000000000000000000000 ()
>> sync_client[18232]: Discarding: 4 0
>> 0000000000000000000000000000000000000000 (\answered)
>> sync_client[18232]: Discarding: 5 0
>> 0000000000000000000000000000000000000000 ()
>>
>> and a bunch more, like:
>>
>> sync_client[18232]: Discarding: archief.thuispc
>> ...
>> sync_client[18232]: sync_eatlines_unsolicited(): resynchronised okay
>> ...
>> sync_client[18232]: Processing sync log file
>> /data/config/imap/sync/log-18231 failed: Bad protocol
>> sync_client[18231]: process 18232 exited, status 1
>>
>> Any clue why replication stopped working properly for me after the
>> upgrade?
>
> There is more sync-related uglyness in my logging; while I suppose this
> is the most harmless one:
>
> sync_client[19532]: Hit upload limit 0 at UID 180958 for user.paul.Junk,
> sending
>
> ... I don't recall seing it before. (And a limit of 0?!)
>
> What is worse, is that sync_client now also segfaults on the
> rolling-log, as soon as I start a sync_client -v -r -f log,
>
> MAILBOXES user.henny user.henny.Email lists.IETF-announce
> user.paul.Drafts archief.netmaster.spam user.elise
> Segmentation fault
>
> And my kernel logs that as:
>
> sync_client[18881]: segfault at 0000000000000000 rip 0000002a96054a30
> rsp 0000007fbfffda08 error 4
>
> ... unfortunately, the sync-log is only getting bigger, and I didn't
> realize that running a sync_client -r -f log would take that much IO and
> CPU (or that is something that changed in this version too).
>
> Somehow I'm not sure if running a reconstruct on all mailboxes is an
> option, it would also take a huge amount of time. But somehow I don't
> think it makes sense.
>
> I'll include my imapd.conf below, in case that is useful.
>
> Paul
>
> P.S. Hmm, and I intentionally skipped 2.3.10 as I believe that people
> were having problems with that, and waited a bit with 2.3.11 :-S

I'm not using replication but IIRC there were some changes between 2.3.9
and 2.3.11 which have to be addressed when using replication. Did you
carefully check the upgrade instructions? Maybe there is something you
have to do.
Another note: Be aware that the invoca rpm has some changed defaults for
imapd.conf (which is stated in the manpage). Now, if one feature doesn't
play nice with replication, this won't disturb other people who don't have
those options enabled. Options that come to mind are:

delete_mode: delayed
expunge_mode: delayed
flushseenstate: 1

Sorry if it doesn't really help.
Simon

>
> My imapd.conf on the master:
>
> configdirectory: /data/config/imap
> defaultpartition: imap4
> partition-imap1: /data/imap1
> partition-imap2: /data/imap2
> partition-imap3: /data/imap3
> partition-imap4: /data/imap4
> sievedir: /data/config/sieve
> hashimapspool: false
>
> md5_dir: /data/config/md5
>
> allowanonymouslogin: no
> allowplaintext: yes
> plaintextloginpause: 0
> admins: cyrus
> sasl_pwcheck_method: saslauthd
> sasl_mech_list: PLAIN LOGIN
> #sasl_pwcheck_method: auxprop
>
> duplicatesuppression: 1
> quotawarn: 90
> postuser: shared
> lmtp_downcase_rcpt: yes
> username_tolower: yes
>
> sieveuserhomedir: false
> unix_group_enable: 1
>
> sync_host: ...
> sync_authname: cyrus
> sync_password: ...
>
> sync_machineid: 2
> sync_log: true
>
> # default invoca-rpm db definitions on this machine!
> ## explicit database definitions (from the past)
> ##duplicate_db: skiplist
> ## deliver.db: Berkeley DB (Btree, version 8, native byte-order)
> #duplicate_db: berkeley
> #mboxlist_db: skiplist
> ## mailbox keys?
> #mboxkey_db: skiplist
> #seenstate_db: skiplist
> #subscription_db: flat
> ##tlscache_db: skiplist
> ## tls_sessions.db: Berkeley DB (Btree, version 8, native byte-order)
> #tlscache_db: berkeley
> #annotation_db: skiplist
> ##ptscache_db: skiplist
> #ptscache_db: berkeley
> #quota_db: quotalegacy
>
> # without this, I got errors in my test-setup using the dovecot imaptest
> expunge_mode: immediate
>
> ----
> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
>