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.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
