ERROR cannot read info: lock timeout exceeded

[Tim Penhey]

The lock isn't there to guard against the same process, but other processes.

I think a safer approach would be to look at the timestamp of the lock
file. If it is greater than just a few seconds, we should break the lock.

Tim

On 28/09/15 20:39, John Meinel wrote:
> Although given https://pad.lv/1467331 it would seem that we can easily
> leave it stale if the client doesn't exit cleanly. This does sounds like
> a case where using a lock file means we're going to need to provide some
> sort of "break-lock" functionality. We could do something like inspect
> the lock and look for a process with the same PID as in the lock file
> and if it doesn't exist break it automatically. This assumes all local
> access, (so sharing $HOME over NFS is risky).
> 
> John
> =:->
> 
> 
> On Mon, Sep 28, 2015 at 12:42 AM, Tim Penhey <tim.penhey at canonical.com
> <mailto:tim.penhey at canonical.com>> wrote:
> 
>     The code does just hold the lock for the duration of the read or write.
> 
>     Since it is possible to have multiple environments sharing a server, and
>     the server data, the access to that data is synchronized.
> 
>     There *shouldn't* be a case where the lock is held but not released.
> 
>     The lock file itself should hold some information about who locked it
>     and why.
> 
>     Tim
>