Two bugs and round-about fixes: Bug #1: I've noticed, for a few years or more, that mbsync will sometimes appear to hang. That is, it will stop making progress in syncing mail and stay in this state. I've noticed it stay stuck for up to a day or two, when I would kill the mbsync process. I would see a hang in the neighborhood of once a month. A couple years ago, now, I would attach gdb when this would happen and would typically find the process in SSL functions. I've also seen apparent hangs after mbsync printed "Disconnecting...". Unfortunately, tracking down the bug looked like it'd take longer than I felt I had, so I didn't get any closer to a direct fix. I've seen this with the stock mbsync and Ubuntu's mbsync, using the courier IMAP server over SSL on one end and local Maildirs on the other.
However, I did write a watchdog, "socketwatch", that kills mbsync when it detects what might be a hang. It can be wrong, of course. The network may have dropped out for several minutes, for example. But the harm it inflicts is just a restart. As long as the apparent hang periods go away soon enough, it will at most delay mail synchronization. I have been using socketwatch for the past year and wanted to others know that it is now released, with mswatch. For anyone interested in only the socketwatch portion of mswatch (a mail synchronization daemon), you can build and install socketwatch without the rest of mswatch. socketwatch detects hangs in mbsync by running mbsync as a child process, with an LDPRELOAD library that notifies the socketwatch parent process of socket reads and writes. If no reads and writes are performed for a certain period, the socketwatch process kills mbsync and then exits with an error. Whatever started socketwatch and mbsync can then try again (mswatch does this). http://mswatch.sourceforge.net/ Bug #2: I've noticed that mbsync can fail to sync a mailbox, print an error that it has failed, but then exit with a status of 0 (success). This is a problem for mbsync because mbsync assumed that a sync error would always cause mbsync to exit with an error. (Upon error, mswatch would retry the sync. Eventually it'll work. Hopefully :).) FWIW, my current work-around with mswatch is to limit the maximum inter-sync period for each mailbox. If a mailbox goes without a sync for longer than this period, mswatch runs syncs the mailbox even though there have been no changes to it. I'm OK with this solution; the overhead of a daily, say, sync for all mailboxes is plenty small for me. Thanks again for mbsync, -- Chris Frost http://www.frostnet.net/chris/ ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
