ERROR cannot read info: lock timeout exceeded

[Tim Penhey]

I added a low-hanging fruit tech-debt card to the board.

https://bugs.launchpad.net/juju-core/+bug/1500613

Tim

On 29/09/15 09:50, Tim Penhey wrote:
> 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
>>
> 
>