After crash, it leaves lock files. Must reboot to run again.
christocoleman at yahoo.com
Wed Aug 31 08:04:03 BST 2011
On Tue, 30 Aug 2011 11:20:58 -0700 (PDT), chris coleman wrote:
> After a crash (steps to reproduce: disconnect the internet during the middle of a run), it leaves lock files on the disk.
Current OfflineImap always leaves the lock file existing, it just
request an exclusive lock via fcntl when it wants to take it. This way
the lock is going away when the process has gone away even if the lock
file is still there.
I have still the patch series to introduce per-account locking (and it
will clean up locks when it doesn't crash), but the locking method will
be the same: taking an exclusive lock.
If it doesn't work after a "crash" I would be very surprised (I believe
you though :-)). The locking code hasn't changed in ages.
If I understand correctly, the lock is a secondary artifact of the actual exclusive lock object, which exists inside fcntl, and when our offlineimap python process crashes, the lock object is unlocked, and the file is also unlocked.
To me, this implies that, on startup of offlineimap, the initialization procedure should be updated to try to delete the lock file(s), and if succesful, this proves that there is no currently running offlineimap process, so by deleting the lock file(s) we just effectively did some garbage collection.
But if deleting those lock file(s) fails, then this proves there is another offlineimap process currently running, so the code should exit with this info message.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OfflineIMAP-project