Created at:

OfflineIMAP notes

*Important:*

OfflineIMAP is a great program. It has some advanced features, allows python code in configuration files (for filters, for intance) and so on. But has serious problems like crashing, huge memory consumption and slowness. After taking a looking at the internet, I found mbsync, which is really easy to setup, very well designed, stable like a rock and really, really fast! (albeit simplier). Try it yourself :-)

OfflineIMAP

mbsync

Troubleshooting

... socket error: <type 'exceptions.IOError'> - Too many read 0

This is a very strange error and there is a lot of information on the internet. I'm using version 6.3.4 of OfflineIMAP_ and it seems it is a safe version, because, according to the link below newer ones introduced a bug that can output the same error.

Gentoo Forums

Fortunatelly, I soon discovered it was a problem on the IMAP server (I work next to the admin of the mail server), which was a problem on the Dovecot IMAP server.

Dovecot

Looking at the Dovecot log messages, we see this error:: 

    Warning: Inotify instance limit for user 240 (UID vmail) exceeded, disabling. Increase /proc/sys/fs/inotify/max_user_instances

So, the first thing was to just increase /proc/sys/fs/inotify/max_user_instances.

The error persists. Looking again at the logs, it told us:: 

    Remote closed connection (process_limit reached?)

After looking at the internet, we discovered that it was necessary to process_limit parameter in Dovecot configuration file.

But the error still persisted and it seemed that it happened only to me. Searching for entries about my user in the logs, we found the line:: 

    dovecot: imap Error: Corrupted index cache file ...path/dovecot.index.cache: Broken physical size for mail ...

It seems Dovecot keeps a cache of the e-mails and the cache for some messages was corrupted. (Maybe something related to OfflineIMAP, since it happened just to me and I was playing with nametrans stuff just before). The e-mail admin told me that, whenever dovecot finds a corrupted index cache file, it rebuilds the index automatically. OfflineIMAP, then, exited with error and waited for the next iteration. My dirty solution, therefore, was run offlineimap in a loop (getting a lot of Too many read 0 errors) until dovecot rebuilt all index cache files.

nametrans

See how interesting it is. For a apparently simple client problem we discovered other server problems.

OperationalError: unable to open database file

(2015-09-10)

This is a bug in OfflineIMAP v6.5.6, fixed in v.6.5.7-rc2, as seem in the link below.

status_backend=plain doesn't work . Issue #133

In my case, it happened because the status file of the folder on ~/.offlineimap directory was corrupted because of a system crash. Deleting this file and setting status_backend = plain in ~/.offlineimaprc didn't help.

The solution I found (very bad, though) was to delete the status file (e.g.:, ~/.offlineimap/Account-XXX/LocalStatus/folder_name and the entire folder in $MAIL directory and resync everything again.