codehosting misattributes locks to supermirror@vostok, rather than the client that created them.

This is weird. The only internal service that would take locks there would be the supermirror_pull.py (branch-puller) script. But it should only ever take read locks, and those are not backed by a filesystem lock, are they?

Users can create lock there by sftp, but then what they put in the log file is out of our control, or by bzr+ssh. Maybe taking a lock by bzr+ssh make it appear to come from supermirror@vostok?

This has just happened to me when running 'bzr push --overwrite bzr+ssh://<email address hidden>/~daniel-thewatkins/bzr/fix-for-116143-2'. I had an interrupted push using bzr+ssh and, despite breaking a lock once, I still have a lock showing up. After entering my passphrase I get the following output from bzr:
"Unable to obtain lock lp--1217229524:///lock
held by supermirror@vostok on host vostok [process #6311]
locked 24 minutes, 41 seconds ago
Will continue to try until 14:05:26

bzr: ERROR: Could not acquire lock (remote lock)"

It also seems that the lock is taken again immediately I use 'bzr break-lock bzr+ssh://...'. This is possibly a bzr+ssh problem?

On Thu, 2007-08-30 at 13:11 +0000, Daniel Watkins wrote:
> It also seems that the lock is taken again immediately I use 'bzr break-
> lock bzr+ssh://...'. This is possibly a bzr+ssh problem?

The supermirror bzr-serve runs as the supermirror account, which is why
it doesn't list your name.

You can try break-lock over sftp, but the bzr serve break-lock *is*
tested.

-Rob

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

I got this too:

ceefour@ojalanow:~/project/bukuruby/web$ bzr push bzr+ssh://<email address hidden>/~ceefour/bukuruby/web
No handlers could be found for logger "bzr"
bzr: ERROR: Could not acquire lock (remote lock)

Still doesn't work :-(

ceefour@ojalanow:~/project/bukuruby/web$ bzr break-lock bzr+ssh://<email address hidden>/~ceefour/bukuruby/web Break lock bzr+ssh://<email address hidden>/%7Eceefour/bukuruby/web/.bzr/branch/lock
held by <email address hidden> on host ojalanow [process #24737]
locked 474 hours, 26 minutes ago? [y/n]: y
Break lock bzr+ssh://<email address hidden>/%7Eceefour/bukuruby/web/.bzr/repository/lock
held by <email address hidden> on host ojalanow [process #24737]
locked 474 hours, 27 minutes ago? [y/n]: y
ceefour@ojalanow:~/project/bukuruby/web$ bzr push
Using saved location: bzr+ssh://<email address hidden>/~ceefour/bukuruby/web/
No handlers could be found for logger "bzr"
bzr: ERROR: Could not acquire lock (remote lock)

ceefour@ojalanow:~/project/bukuruby/web$ bzr break-lock bzr+ssh://<email address hidden>/~ceefour/bukuruby/web Break lock bzr+ssh://<email address hidden>/%7Eceefour/bukuruby/web/.bzr/branch/lock
held by supermirror@vostok on host vostok [process #18803]
locked 12 minutes, 11 seconds ago? [y/n]: y
Break lock bzr+ssh://<email address hidden>/%7Eceefour/bukuruby/web/.bzr/repository/lock
held by supermirror@vostok on host vostok [process #18803]
locked 13 minutes, 38 seconds ago? [y/n]: y

Hendy: there's a bug with break-lock over bzr+ssh tob bazaar.launchpad.net (see bug 148087). As a workaround you can use "bzr break-lock sftp://<email address hidden>/%7Eceefour/bukuruby/web".

We can easily override the first part of the message by setting thr $BZR_EMAIL environment variable (to e.g. <email address hidden>).

This would give us a message like "held by <email address hidden> on host vostok", which is not perfect but is better.

Yeah, this has been driving me nuts on my branch: bzr+ssh://bazaar.launchpad.net/~burner/memaker/memaker-burner/

Why are these locks being held for so long? Is there a way to avoid having to break a lock so often? On my branch, I'm the only one using it, and I'm using gutsy's version of bzr...

Usually, for archives that are written to by a single person, those are stale locks. This is why bzr tells you how long ago a lock was created: if it was created a day ago, it is almost certainly stale and safe to delete using "bzr break-lock".

Stale locks cannot be avoided when using the sftp transport, or any other filesystem-based transport. If your sftp connection is brutally interrupted, bzr does not have a chance to release the lock.

The bzr+ssh:// instead of sftp:// transport (supported today by Launchpad) should not have this problem: if the connection is interrupted, the server-side bzr process can still release the lock.

Hm... but I only use bzr+ssh, and I don't interrupt my connections!

And yeah, it happens every time I do a non-null push (just hit by it again). [that is, a push that actually sends a new revision to the lp branch]

David Allouche wrote:
> The bzr+ssh:// instead of sftp:// transport (supported today by
> Launchpad) should not have this problem: if the connection is
> interrupted, the server-side bzr process can still release the lock.

This may be true eventually, when the bzr+ssh:// protocol has implemented
everything in terms of high-level domain objects. At the moment almost every
operation falls back to file-level requests, which means taking out file-level
locks of exactly the same sort as SFTP.

So using bzr+ssh:// will not avoid stale locks, at least not today.

1.10 changed the reporting so that instead of supermirror@vostok, the lock is owned by <username>@bazaar.launchpad.net. Ideally we'd change the hostname to refer to the client's address, but AIUI this requires changes to Bazaar.

I've yet to confirm that this has been released, as bug 152746 is getting in the way.