How to detect out-of-sync condition

[Cliff Hayes]

I tried to look at a dovecot.index.log and it was unreadable in a text 
editor.  I didn't see anything in the wiki link about how to view the log.

So I guess I'll just be guilty of excessive optimizing.
Should I run a daily doveadm index or resync?

On 3/13/2015 6:00 PM, Joseph Tam wrote:
> On Fri, 13 Mar 2015, Cliff Hayes writes:
>
>>> By closing off other avenues other than dovecot imap/pop/lda/etc.,
>>> the indices will stay sync'd.
>>
>> I use dovecot's lda and dovecot's sieve filter.
>
> Then I'm not sure how mailboxes ever get out of sync.
>
>> So it looks like I need to compare the index/mailbox mtimes as you
>> suggest.
>>
>> What am I looking for?
>> I see that the indexes are updated when I run the resync.
>>
>> I checked my mailbox (that was not resynced) and noticed that
>> dovecot.index last update was 16 days ago.
>
> Just to be clear, you're talking "doveadm index ...", yes?
>
> You might have to check dovecot.index.log* as well as they could contain
> the latest changes that have yet to propagate to the main index file.
>
>      http://wiki2.dovecot.org/Design/Indexes/TransactionLog
>
>> So am I resyncing if the gap is over x days?
>> If so, is there a way to resync just those mailboxes with a doveadm
>> command or do I have to write a program look for that condition and run
>> doveadm when matched?
>
> It's possible that "doveadm index" checks modification times as an
> optimization measure.  My recommended game plan:
>
>      1) Are your indices *really* out of date (checks logs as
>      Steffen recommends)?
>
>      2) If so, how do they get out of date and can you avoid it?
>
>      3) If you can't avoid it, does it cause real problems?  Most
>      of the time, dovecot will seemlessly rebuild it and
>      it's transparent to the user.
>
>      4) If you got this far, run a trial "doveadm index -A INBOX"
>      (assuming you're just concerned about INBOXs) to see if it's
>      really such a bad operation.  As Knuth (hallowed be thy
>      name!) said, "premature optimization is the root of all evil."
>
> Only after all these steps are found to be unsatisfactory would I consider
> writing your own scan and fix tool.
>
> Joseph Tam <jtam.home at gmail.com>
>