bzr: ERROR: Could not acquire lock [Errno 11] Resource temporarily unavailable

[Vincent Ladeuil]

When using bzr viz or bzr gannotate, I can't commit with bzr, it fails with:

bzr: ERROR: Could not acquire lock [Errno 11] Resource temporarily unavailable

If I quit bzr viz or bzr gannotate, all is well.

[John A Meinel (jameinel)]

I'm not sure if this is a bug in bzr, or a bug in bzr-gtk, or if it is actually a "design feature".

Specifically, the problem is that bzr-gtk is locking the tree in read-only mode. Which sort of indicates (to me) that you shouldn't be able to write to it (since it is readonly).

In the past, our read-locks were no-ops because our data structuring generally meant that a writer could not invalidate a reader. But the way we write dirstate now means there is a potential race condition (I'm reading while you are writing), so we use a read lock.

A few possible solutions:

a) Does 'bzr gannotate' need to keep a read-lock on the WT? It could probably grab one when it starts annotating, and then release it once it has the display running.

b) Does 'bzr viz' need a WT lock at all. I could understand it having a Branch lock, but those *are* no-op read-locks.

c) Is it just that this error is not as clear as it could be? "Resource Temporarily Unavailable" versus "Could not lock tree for writing" or "Tree is locked readonly" or something else.

I'll include bzr-gtk as part of this bug, and we can sort out what we want to do about it.

Note, that this also happens for "bzr diff | less" if it is long enough to block the pipe, and then "bzr commit". Or especially "bzr commit" popping up the message editor, and running "bzr diff" in another window.

The fact that we pun read-lock with the length of time to cache information in memory might also be evaluated. But honestly, it is only *safe* to cache if you have a lock, so that you know things aren't changing.

We've also discussed changing things again so that we can avoid OS locks entirely. They seem nice in a lot of ways, (they clean up after themselves, etc), but if we avoid them we structure code closer to not having locks at all (no-op read locks) which has its own benefits.

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> a) Does 'bzr gannotate' need to keep a read-lock on the WT? It could
> probably grab one when it starts annotating, and then release it once it
> has the display running.

It can generate diffs. I'm not sure whether that means it should be
grabbing WT locks when it generates them.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGgT+u0F+nu1YWqI0RAtJEAJ9w+jU98s3Trk0vZevBOevb5TTx0QCfXUpE
tyhtn2mCxZYkFQoMi2Fs1oU=
=s7LO
-----END PGP SIGNATURE-----

[John A Meinel (jameinel)]

Well 'gannotate' should also be doing a WT.annotate_iter() to mark any lines that are changed in the source tree/merged from another branch.
I'm just thinking that it could potentially grab a longer-term branch lock, and only lock the WT when it is actually getting something out of it.

[Robert Collins (lifeless)]

On Tue, 2007-06-26 at 16:32 +0000, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John A Meinel wrote:
> > a) Does 'bzr gannotate' need to keep a read-lock on the WT? It could
> > probably grab one when it starts annotating, and then release it once it
> > has the display running.
>
> It can generate diffs. I'm not sure whether that means it should be
> grabbing WT locks when it generates them.

In general any call to WT methods will either acquire a lock, or require
one. I'm not aware of state that is lock-free at the moment there. I
think using granular locks which you acquire and release as needed from
long lived gui's is a good idea.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Wouter van Heyst (larstiq)]

The error message bzr itself gives is very vague though, I just ran into this problem with resolve:

>> bzr resolved NEWS
bzr: ERROR: Could not acquire lock [Errno 11] Resource temporarily unavailable

Running with -Derror gives some more info:

>> bzr resolved NEWS -Derror
bzr: ERROR: bzrlib.errors.LockContention: Could not acquire lock [Errno 11] Resource temporarily unavailable

Traceback (most recent call last):
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/commands.py", line 729, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/commands.py", line 691, in run_bzr
    ret = run(*run_argv)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/commands.py", line 389, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/conflicts.py", line 117, in run
    resolve(tree, file_list)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/conflicts.py", line 121, in resolve
    tree.lock_tree_write()
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/workingtree_4.py", line 616, in lock_tree_write
    self._lock_self_write()
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/workingtree_4.py", line 600, in _lock_self_write
    state.lock_write()
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/dirstate.py", line 2350, in lock_write
    self._lock_token = lock.WriteLock(self._filename)
  File "/home/larstiq/src/bzr/bzr.dev/bzrlib/lock.py", line 146, in __init__
    raise errors.LockContention(e)
LockContention: Could not acquire lock [Errno 11] Resource temporarily unavailable

[Launchpad Janitor (janitor)]

[Expired for Bazaar because there has been no activity for 60 days.]

[TimeHorse (timehorse)]

I am seeing this issue too. I do not use gannotate or viz or any GTK. I am just checking out a straight, exclusive Python branch. I have seen this once before and found no way to cure it! It is extremely vexing because once this occurs, it is permanent and a whole new fresh checkout of the 1/3 gb of data in the Python repository must be downloaded fresh and one must start again! This takes an EXTREMELY long time. And this seems to effect every bzr operation from switching to merging.

Here is my error report:

bzr: ERROR: bzrlib.errors.LockContention: Could not acquire lock "[Errno 11] Resource temporarily unavailable"

Traceback (most recent call last):
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/commands.py", line 846, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr
    ret = run(*run_argv)
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/builtins.py", line 4497, in run
    switch.switch(control_dir, to_branch, force)
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/switch.py", line 39, in switch
    _update(tree, source_repository)
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/switch.py", line 121, in _update
    tree.lock_tree_write()
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/workingtree_4.py", line 621, in lock_tree_write
    self._lock_self_write()
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/workingtree_4.py", line 605, in _lock_self_write
    state.lock_write()
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/dirstate.py", line 2734, in lock_write
    self._lock_token = lock.WriteLock(self._filename)
  File "/home/crew/user/lib/python2.5/site-packages/bzrlib/lock.py", line 146, in __init__
    raise errors.LockContention(e)
LockContention: Could not acquire lock "[Errno 11] Resource temporarily unavailable"

bzr 1.5 on python 2.5.2 (linux2)
arguments: ['/home/crew/user/bin/bzr', 'swre9+10', '-Derror']
encoding: 'ANSI_X3.4-1968', fsenc: 'ANSI_X3.4-1968', lang: None
plugins:
  bzrtools /home/crew/user/lib/python2.5/site-packages/bzrlib/plugins/bzrtools [1.5.0]
  checkeol /home/crew/user/lib/python2.5/site-packages/bzrlib/plugins/checkeol [1.2.1]
  diffstat /home/crew/user/lib/python2.5/site-packages/bzrlib/plugins/diffstat [unknown]
  launchpad /home/crew/user/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
  lessdiff /home/crew/user/lib/python2.5/site-packages/bzrlib/plugins/lessdiff [unknown]
  lesslog /home/crew/user/lib/python2.5/site-packages/bzrlib/plugins/lesslog [unknown]
  rebase /home/crew/user/lib/python2.5/site-packages/bzrlib/plugins/rebase [0.3.0]
  stats /home/crew/user/lib/python2.5/site-packages/bzrlib/plugins/stats [unknown]
*** Bazaar has encountered an internal error.
    Please report a bug at https://bugs.launchpad.net/bzr/+filebug
    including this traceback, and a description...

[Jasper Groenewegen (colbrac)]

Confirmed for bzr-gtk trunk (555)
bzr gcommit runs with bzr vis open when both started are from shell and when started from olive
bzr gcommit only runs with bzr gannotate open when both are started from olive. When both are started from shell, bzr gcommit complains.
bzr vis runs with bzr gcommit open when both started from shell
bzr gannotate doesn't run with bzr gcommit open when both started from shell
From olive gcommit takes focus and doesn't allow running another dialog

So currently the pain in bzr-gtk is with gannotate keeping a lock when started from shell but not when started from olive

[John A Meinel (jameinel)]

At the moment, I think this needs to be a fix in bzr-gtk.
Long term, there is a possibility to get rid of OS locks and return to a read lock being a no-op, but that is a different bug/feature request.

[kentarok (kentarok)]

The real problem is that bzr has not friendly way to clear the lock file, in the case where, for example, kdiff3 crashes and leaves the tree in that "locked" state. So the "temporary" problem becomes permanent.

If one of bzr's commands could clean up that problem, then it would help. For example, if "bzr check" would say something like:

"If this problem appears permanent, ensure no other programs are using the trye, then use:
bzr check --unlock --force".

Or something like that.

Most hardcore developers prob. manually delete the lock file,
others reboot the system or just form another branch as a workaround,
or use git instead (with github being so popular),
but the really friendly solution would be to make bzr smart enough to either
a) check to make sure the lock is still need,
or
b) allow the operator to break the lock and return the tree to a usable state.

I don't know if (a) is possible, but (b) should be, even if it is dangerous is used incorrectly.

Which is why I suggest the --force option.

[Vincent Ladeuil (vila)]

@kentarok: 'bzr break-lock' should fit your needs ?