On Fri, May 31, 2013 at 8:47 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> That's OK for manual investigation, but we're looking for a solution that suitable for building into infrastructure management scripts, so it needs to be portable and reliable, and stable across OS upgrades and the like.
Repositories on network storage also complicates this.
We could use the contents of the write-lock file to store some details
of who has the lock and possibly why (is it a freeze or not). When
someone takes out a write lock they'd open the file with an exclusive
lock and write out the details into the file. There would be a brief
period where the data was unavailable, but we have to deal with that
anyway because older code won't be writing this data out anyway.
Given that freeze was intended for backup purposes I think a timeout
for the lock is needed. People need a way to know that the backup
failed. Without a timeout a permanently write-lock repo would just
stack up more and more freeze commands as cron tried to run future
backups. We've essentially made that more likely with the freeze
command since if the command freeze is running never exits the write
lock never gets returned.
Received on 2013-05-31 18:17:56 CEST