lock oddity
John Arbash Meinel
john at arbash-meinel.com
Tue Nov 20 21:14:09 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wichmann, Mats D wrote:
> We have some autobuild setups that pull from official
> branches. In tracing some stuff on one of the machines,
> I tried to manually do a pull in one of the local
> branches and was met with:
>
>
> Unable to obtain lock
> file:///home/autobuild/tmp/LSBauto/vsw4-test/.bzr/repository/lock
> held by autobuild at fsgdev-ia64 on host fsgdev-ia64 [process #9488]
> locked 1106 hours, 5 inutes ago
> Will continue to try until 18:52:38
>
I had something similar happen. Only I believe mine was a 2000+ hour old stale
lock.
>
> This is a little silly, that's a 46-day-old lock.
> The machine is somewhat flaky, and probably
> crashed while holding this lock. The process is
> definitely not still running, the machine has only
> been up for 6 days this last time!
The problem with setting a limit, is that all limits are essentially arbitrary.
Some might say that a lock held for longer than 1 hour is strange. But then you
get the person who is pushing their Mozilla source tree over dialup, because
that is all they have.
I would probably say that your build process should be more forceful about
complaining when updating fails. I'm pretty sure 'bzr pull' returns a different
code if there are no changes versus if there are changes versus if something
else fails (could not connect, lock timeout, etc.).
I would guess that 1 week would be a "reasonable" time to auto unlock. Though I
also think our approach with packs is even better. Which is to minimize the
amount of time that you actually hold a lock, which minimizes the window for
stale locks.
Knit repositories hold the lock the whole time they are transferring data. Pack
repositories can copy the data up, and then just grab the lock for long enough
to mark the new file "visible".
We also need to be rather conservative about locks. Because if you get 2 people
writing to a knit repository at the same time, you can get corruption if they
try writing to the same files. We only append data, but the appends could get
interleaved between the two. We would detect this the next time we tried to get
the data (most likely the gunzip will fail quickly, but if not when we extract
the sha1 will miss.)
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHQ04hJdeBCYSNAAMRAh3bAJ90f2RijK7pWeLX1tfqein3TMSquACgs14n
vziiH2V073dHpv29bKSD7Mo=
=etgT
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list