After crash, it leaves lock files. Must reboot to run again.

[chris coleman]

On 31Aug2011 00:04, chris coleman wrote:

| Sebastian wrote:
| > 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. [...]
| > 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.

Sounds like it.

| To me, this implies that, on startup of offlineimap, the initialization procedure should be updated to try to delete the lock file(s),

Why? All that seems to be needed is no lock, not no lock file.

| and if successful, 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.

I would expect deletion of the lock file to work even if it is locked;
delete only needs write on the directory, not write on the file itself.

Does offlineimap actually not run for you after a crash? Of do you just
not believe it will run? It sounds like more detail of the actual
failing behaviour is needed, since the lock file _should_ not be the cause of
the trouble.

Disclaimer: I am not an offlineimap developer.,

Cheers,
============================================


After the crash: offlineimap failed to start again. It gave an error like "Another offlineimap is currently running, so this one will exit now, so as to avoid corrupting any data..."  

The problem was: offlineimap was stalled for far too long (hours) and was going to stay stuck waiting forever for a response from the remote server, because the net connection dropped while sync'ing 10 or 20 messages, then the net reconnected, and it still was waiting on the old connection but would never see it.  It had to be made to restart.

I see this on the File Locking page on wikipedia: "All fcntl locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process, even if a lock was never requested for that file descriptor. Also, fcntl locks are not inherited by a child process. The fcntl close semantics are particularly troublesome for applications that call subroutine libraries that may access files."

By default, file locking on unix/linux is ADVISORY.  "Mandatory locks have no effect on the unlink function. As a result, certain programs may, effectively, circumvent mandatory locking. The authors of Advanced Programming in the UNIX Environment (Second Edition) observed that the ed editor did so (page 456)."

Is it possible the implementation of locking in offlineimap might be based on mandatory locking, not advisory locking ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/offlineimap-project/attachments/20110906/24bb047e/attachment.html>