Bazaar doesn't detect its own stale locks

Bug #220464 reported by Stefan Monnier on 2008-04-22
2
Affects Status Importance Assigned to Milestone
Bazaar
High
Martin Pool
Breezy
High
Unassigned

Bug Description

Here's a sample session:

  % bzr commit -m '...'
  Unable to obtain lock sftp://iro/%7E/var/bzr/emacs/work/.bzr/branch/lock
  held by <email address hidden> on host pastel [process #4601]
  locked 6 hours, 59 minutes ago
  Will continue to try until 22:20:36

and then it sits there. Thing is, this is on "pastel", and there is no process 4601 running, so the lock can be determined to be stale without the need of any user interaction.

Related branches

Martin Pool (mbp) wrote :

If the holder hostname is the same as the new process's hostname we could check if the process still exists.

I have some concern that the hostname may not be unique to a physical machine, such as if it was never set (so is "localhost"), or if it's set to a static value (like "ubuntu") by a boot cd. But it's probably unlikely that the username will also match in this case.

Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
Martin Pool (mbp) on 2010-09-15
tags: added: lockdir locking
Martin Pool (mbp) wrote :

Detecting and automatically cleaning them up is probably more reliable than trying to always make sure we release them before closing down, which is what bug 257217 asks for.

Changed in bzr:
assignee: nobody → Martin Pool (mbp)
importance: Medium → High
status: Confirmed → In Progress
Martin Pool (mbp) wrote :

Is there any value asking about breaking if we know it's stale, or should we just do it (with a notification to the user?) I can think of contrived cases where we'll get it wrong but it seems like most of the time we'll just be getting in the way.

> Detecting and automatically cleaning them up is probably more reliable
> than trying to always make sure we release them before closing down,
> which is what bug 257217 asks for.

It's not an either/or: stale locks are inevitable but are a pain in the
rear so they should be avoided as much as possible. I.e. Bazaar should
try to automatically clean stale locks *and* it should try harder to
clean after itself when it exits unexpectedly so as to avoid leaving
stale locks around (because automatic detection is often impossible
when the lock is help by some remote process).

        Stefan

Martin Pool (mbp) wrote :

On 15 September 2010 18:08, Stefan Monnier <email address hidden> wrote:
>> Detecting and automatically cleaning them up is probably more reliable
>> than trying to always make sure we release them before closing down,
>> which is what bug 257217 asks for.
>
> It's not an either/or: stale locks are inevitable but are a pain in the
> rear so they should be avoided as much as possible.  I.e. Bazaar should
> try to automatically clean stale locks *and* it should try harder to
> clean after itself when it exits unexpectedly so as to avoid leaving
> stale locks around (because automatic detection is often impossible
> when the lock is help by some remote process).

Yes, I agree both are useful, I'm just planning to do this side of it first.

--
Martin

Martin Pool (mbp) wrote :

bzr 2.4 will be able to do this. If you set 'locks.steal_dead = True' in eg ~/.bazaar/bazaar.conf or locations.conf, in cases where it is able to tell the lock is dead (specifically, coming from the same client). We have not yet set this by default, but we can look at doing that in future. Please turn it on and let us know if it helps.

Vincent Ladeuil (vila) wrote :

In the mean time, I'm marking this bug as fix released as it will be included in 2.4b4.

Changed in bzr:
milestone: none → 2.4b4
status: In Progress → Fix Released
Jelmer Vernooij (jelmer) on 2020-06-08
Changed in brz:
status: New → Fix Released
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers