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.pen...@canonical.com > <mailto:tim.pen...@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 > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
