On Monday, July 11, 2016 05:38:20 PM Remko Lodder wrote: > > On 11 Jul 2016, at 17:21, William L. Thomson Jr. <wlt...@o-sinc.com> > > wrote: > > > > You are not alone! > > Hello, > > Now that’s a relief!
Maybe if I had a solution, but I guess knowing others suffer the same can be reliving. > One of the things that I described and observed is that it seems that > serverB is not seeing the email (or at least there is no connection that > when an email is send and stored on the mailserver that the services see > them and notify the other end). With tcpdump there is no traffic at all, > until there is a sync the other way around. I really have not had a chance to debug this. I was under the impression one side thought it had synced. Since both sides tend to show fast sync, but its the full sync I have been curious about. When I run the manual command, it seems to do a full sync. Also not clear if emails are supposed to be on both or if one has reference to emails on the other. When I do a manual sync via command line, it seems to make both have the same emails, but different file names. The manual syncing I think it triggers another issue with duplicate emails. Another started a topic on duplicate emails from dsync, which I suffer from as well when I try to force syncing, or as a result of syncing at times. That as well I have not had a chance to debug. > As said both systems are identical in hardware setup and use puppet to > obtain their configuration, which is the same for both hosts (except the IP > adresses and hostname); Same here, I literally cloned my 2nd one as both are VMs. I use Ansible to make them identical configuration wise. Only thing that is different is the data, email that arrives on one or the other. > But since we are with at least two, we might have better luck in getting > some help with this. I currently do not have an idea on where to look and > how to investigate this properly. It seems there might have been a few regressions, maybe or hopefully. Things seemed to get better and/or go away entirely for a month or so after a past updated. I commented about that on list. Though it seems to have regressed with 2.2.24. I haven't upgraded to 2.2.25 yet. Seems that might have other regressions not sure or maybe fixes. > Any pointers from the list are welcome! Beyond running the manual sync via command line, not sure at this time. The manual sync via cli seemed to stop working a few updates back. Just as I type that, I went to run the command again so I could get errors to pass along and it worked. I know I tried to run it the other day and it failed. Something about unable to lookup UID or switch to the users. I had cron running it every 15 minutes to force things to sync. I stopped when I started getting emails of errors when it ran every 15 minutes. I think error is similar for the use case for the dsync wrapper script for root, mentioned here. When I get the error it seems root has a problem changing to another UID. Which seems that is what the script does, wrap users for root. http://wiki.dovecot.org/Replication Just odd that it works sometimes and not others. I thought it stopped working during an update. Now I think it is related to the syncing. Maybe when syncing is not working, if I run that command I will get the errors. Not sure if it will shed any light on syncing. At least I know that is not related to an update or regression. I will see about replicating the manual sync errors, and see if regular syncing is broken at the same time. Beyond that, I am open to any input from the list as well... Though need to do my part and try to debug a bit more. -- William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.com
signature.asc
Description: This is a digitally signed message part.
