Hi!  Thanks to Jean Charles Delépine's reply to my previous message 
<https://cyrus.topicbox.com/groups/info/T186bcddd95bbbfb3/problem-with-mupdate-authentication-on-1-node-cluster>,
 I've set up replication and am trying to get that to work.  However, 
replication attempts (almost) always end with "Error from do_user(username): 
bailing out!" or "Error from do_mailboxes(mailbox): bailing out!", with 
different (but reproducible) failures depending on which user or mailbox I'm 
replicating.  (I've mostly tested -u but with some attempts at -m.)

(I'm using the csync dedicated server, since the production server I'm trying 
to replicate from is pre-3.0.)

For some users, all or almost all mail contents transfer, and then the sieve 
scripts fail with a warning (in logs and the sync correspondence as shown by 
strace'ing one side or the other) that a script couldn't be compiled (but 
leaving nothing in the user's sieve directory).

For some users, the sieve complaint happens first, before any mailboxes are 
transferred, leaving no trace of the user on the replica.

And for some users, the attempt to transfer mailboxes happens first, produces 
something like "IOERROR: GUID mismatch user.[username] [number]" and then 
"do_folders(): update failed: user.[username] 'System I/O error'" in the logs, 
and leaves nothing transferred.  (That IOERROR message can occur for mailboxes 
that exist already on the replica and for mailboxes that do not exist on the 
replica.)

The first few accounts I tried to replicate seemed to get all their mail (but 
not their sieve scripts).  Those were all accounts where I'd rsync'ed and 
reconstruct'ed the user's mailboxes manually (and created a SASL password for 
the user) before switching to replication via sync_client; I deleted the users' 
mailboxes before sync'ing the first time, but presumably Cyrus had some cache 
that such a user had existed.  And since I initially transferred the mailboxes 
via rsync, any GUIDs cached from mailbox databases presumably would have 
matched.

Generally, behavior is consistent for each user.  (E.g., every time I run 
sync_client for my own account, all my mailboxes seem to be synchronized fine, 
and then I get an error trying to synchronize my sieve folders, which shows up 
as "SIEVE received NO response: IMAP_SYNC_BADSIEVE Sieve script compilation 
failure" in the client log, and appears from tracing the server process to 
happen after sync_server confirms that the script doesn't already exist on the 
replica, accepts it from sync_client, and writes it to a test file.  But for 
another account -- whose mailboxes I hadn't previously rsync'ed and then 
deleted -- I consistently see the Sieve-script failure right away and no 
messages transfer, and for a third account I consistently see the "IOERROR: 
GUID mismatch" message right away, and no messages or transferred (nor is the 
user's INBOX created on the replica).

How can I debug this?  strace (of sync_client and sync_server) is telling me 
*some* things, but I can't figure out why sometimes sync_client tries to send 
the sieve scripts first and sometimes tries to send the mailboxes first.  And 
adding -v and -l to sync_client doesn't give me any detail about exactly what 
it's trying to do when it fails.

Jay

PS -- I *have* been able to replicate one account successfully, a test account 
that had very little mail in its INBOX.  That was producing the Sieve warning, 
but synchronizing mail, until I deleted a duplicate Sieve script on the 
production server.  (It had identical scripts "default" and "default.script", 
and byte-compiled script "default.bc".  Deleting "default" caused things to 
succeed.)  Then I was able to have sync_client run for that account without 
errors.  But for my own account, deleting the various test sieve scripts I had 
accumulated and leaving just one script file and one byte-compiled file didn't 
help.
------------------------------------------
Cyrus: Info
Permalink: 
https://cyrus.topicbox.com/groups/info/T7643135b2a3e136a-Me7b0caba21571878aa30a868
Delivery options: https://cyrus.topicbox.com/groups/info/subscription

Reply via email to