You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2013/05/31 14:35:57 UTC
Using "svnadmin freeze"
One of my colleagues at WANdisco asked some questions about using
freeze. The first thing he wanted to know is how to detect whether a
freeze is running. There are various approaches: look at running
processes, look at processes with the lock file open, implement some
external lock, etc. but none are reliable or portable. The only
reliable way to do it is for Subversion to provide some sort of
implementation.
A freeze query might be implemented by having a separate freeze lock.
The freeze function itself would then take the freeze lock before taking
the write lock, and the freeze query would try a non-blocking lock of
the freeze lock. This would probably go into the repos layer to avoid
duplicate implementations.
I think something like that would work but I'm unsure whether we should
provide it. I'm concerned that it would be making freeze special.
Would we need to provide similar queries for upgrade, recover, pack,
etc?
A second point was about adding a timeout to freeze. At present freeze
blocks until it gets the write lock and will wait as long as it takes.
There is no timeout in APR's file locking API so to implement a timeout
we would need to either sit in a loop attempting non-blocking locks or
use SIGALARM to cause EINTR. I think that would work but again I'm
unsure how useful this feature would be.
A timeout leads on to a question was about error handling. At present
the return value of "svnadmin freeze repository program" is the return
value of the external program provided freeze managed to run the
program. If freeze failed to run the program for some reason then the
return value is generated by svnadmin directly. There is no way to
distinguish errors from 'program' from errors from 'svnadmin', they both
return values in the range 0-255. Success, zero, is unambiguous but any
error is difficult to interpret.
I don't see any easy way round this. If we stop providing the 'program'
error as the return value how else do we provide it? Write it to
standard output in some known form? Invoke some post-freeze command and
pass it as a parameter?
--
Philip
Re: Using "svnadmin freeze"
Posted by Ben Reser <be...@reser.org>.
On Fri, May 31, 2013 at 8:47 AM, Julian Foad <ju...@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.
Re: Using "svnadmin freeze"
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
>> On 05/31/2013 10:35 AM, Julian Foad wrote:
>>> Just an opinion from general experience in the world of computers. With
>>> any system where some resource is reserved (locked), it can be useful to
>>> find out who/what has the lock. So, a system that tells me the repo is
>>> currently locked by which of the following:
>>>
>>> commit
>>> pack
>>> freeze
>>> ...
>>>
>>> would be useful, in my opinion. An output that enumerates one of the
>>> above list would be useful.
>>
>> Don't most OSes provide tooling for this, though?
>
> Just to clarify, I'm talking about the likes of this:
>
> $ cd ~/tests
> $ flock lockfile lsof | grep `pwd`/lockfile
> flock 2912 cmpilato 4uW REG 8,5 0 3500312
> /home/cmpilato/tests/lockfile
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.
See Philip's original introduction to this email thread:
> One of my colleagues at WANdisco asked some questions about using
> freeze. The first thing he wanted to know is how to detect whether a
> freeze is running. There are various approaches: look at running
> processes, look at processes with the lock file open, implement some
> external lock, etc. but none are reliable or portable. The only
> reliable way to do it is for Subversion to provide some sort of
> implementation.
(Wording tweak: I'd say "none are reliable *and* portable".)
- Julian
Re: Using "svnadmin freeze"
Posted by Branko Čibej <br...@apache.org>.
On 31.05.2013 17:27, C. Michael Pilato wrote:
> On 05/31/2013 11:23 AM, C. Michael Pilato wrote:
>> On 05/31/2013 10:35 AM, Julian Foad wrote:
>>> Just an opinion from general experience in the world of computers. With
>>> any system where some resource is reserved (locked), it can be useful to
>>> find out who/what has the lock. So, a system that tells me the repo is
>>> currently locked by which of the following:
>>>
>>> commit
>>> pack
>>> freeze
>>> ...
>>>
>>> would be useful, in my opinion. An output that enumerates one of the
>>> above list would be useful.
>> Don't most OSes provide tooling for this, though?
> Just to clarify, I'm talking about the likes of this:
>
> $ cd ~/tests
> $ flock lockfile lsof | grep `pwd`/lockfile
> flock 2912 cmpilato 4uW REG 8,5 0 3500312
> /home/cmpilato/tests/lockfile
> $
I was about to say the same thing; at best we can put a couple examples
in tools/server-side.
-- Brane
Re: Using "svnadmin freeze"
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/31/2013 11:23 AM, C. Michael Pilato wrote:
> On 05/31/2013 10:35 AM, Julian Foad wrote:
>> Just an opinion from general experience in the world of computers. With
>> any system where some resource is reserved (locked), it can be useful to
>> find out who/what has the lock. So, a system that tells me the repo is
>> currently locked by which of the following:
>>
>> commit
>> pack
>> freeze
>> ...
>>
>> would be useful, in my opinion. An output that enumerates one of the
>> above list would be useful.
>
> Don't most OSes provide tooling for this, though?
Just to clarify, I'm talking about the likes of this:
$ cd ~/tests
$ flock lockfile lsof | grep `pwd`/lockfile
flock 2912 cmpilato 4uW REG 8,5 0 3500312
/home/cmpilato/tests/lockfile
$
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Using "svnadmin freeze"
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/31/2013 10:35 AM, Julian Foad wrote:
> Just an opinion from general experience in the world of computers. With
> any system where some resource is reserved (locked), it can be useful to
> find out who/what has the lock. So, a system that tells me the repo is
> currently locked by which of the following:
>
> commit
> pack
> freeze
> ...
>
> would be useful, in my opinion. An output that enumerates one of the
> above list would be useful.
Don't most OSes provide tooling for this, though?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Using "svnadmin freeze"
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Shahaf wrote:
> Philip Martin wrote on Fri, May 31, 2013 at 14:23:35 +0100:
>> Daniel Shahaf <da...@apache.org> writes:
>>> On Fri, May 31, 2013 at 01:35:57PM +0100, Philip Martin wrote:
>>>> I think something like that would work but I'm unsure whether we should
>>>> provide it. I'm concerned that it would be making freeze special.
>>>> Would we need to provide similar queries for upgrade, recover, pack,
>>>> etc?
>>>
>>> I wanted to add "Is a write-lock being held?" to 'svnadmin info'. That was
>>> just on a hunch that it might be useful --- I didn't have a concrete use-case
>>> (and that feature has not been implemented).
>>
>> I guess that would be implemented by a non-blocking attempt to get a
>> lock. Occasionally it would see a commit holding a lock as well as the
>> other longer running commands. I can't decide whether queries like
>> that, or the freeze query, are useful.
Just an opinion from general experience in the world of computers. With any system where some resource is reserved (locked), it can be useful to find out who/what has the lock. So, a system that tells me the repo is currently locked by which of the following:
commit
pack
freeze
...
would be useful, in my opinion. An output that enumerates one of the above list would be useful.
Even better would be an additional output that identifies more specifically which server process or remote process holds the lock (PID, some sort of URL, and/or whatever means of identifying it may be available, if any). This might or might not be uniform enough to be useful as an API, but would certainly be useful for a human admin to look at.
But whether it's worth implementing this amount of detail at this point in time... I don't know.
>>>> A timeout leads on to a question was about error handling. At present
>>>> the return value of "svnadmin freeze repository program" is the return
>>>> value of the external program provided freeze managed to run the
>>>> program. If freeze failed to run the program for some reason then the
>>>> return value is generated by svnadmin directly. There is no way to
>>>> distinguish errors from 'program' from errors from 'svnadmin', they both
>>>> return values in the range 0-255. Success, zero, is unambiguous but any
>>>> error is difficult to interpret.
>>>>
>>>> I don't see any easy way round this. If we stop providing the 'program'
>>>> error as the return value how else do we provide it?
>>>
>>> IIRC, some applications use the following strategy: "If execvp() failed,
>>> exit 126; else, exit with the child's exit code (possibly zero)".
>>
>> At present a failed exec returns 255 (on my machine). The problem is
>> that the external program can also return 255. If we document a value
>> then callers know it is possible that exec failed but can't be sure.
>
> Can't we just ask people who really care about all 8 bits of the child's
> exit code to use the bindings?
Yes -- it's very rare to need to know all possible exit statuses from the child, and in such a case the admin can write a wrapper for the program (that puts the exit code somewhere else) or use the bindings.
Solve the 99% case simply by defining a mapping of exit codes in some lossy way such as:
PROG -> freeze
0 -> 0
1 -> 1
2 -> 2
...
99 -> 99
100..255 -> 100
-- 101..126 'freeze' errors:
-- 101 timeout getting the lock
-- 102 other failure to get the lock
-- 103..125 reserved
-- 126 failed to execute the freeze PROG
-- 255 'svnadmin' itself didn't exist
or whatever.
- Julian
>
>> >> Invoke some post-freeze command and pass it as a parameter?
>> >
>> > I suppose the post-freeze command should be optional?
>>
>> I think so but I'm not sure how, or even if, it would work. Would we
>> simply have the the same problem of how to return the post-freeze
>> command status?
>
> We'd have the failure mode that the freeze-hook failed to run (or ran
> and exited non-zero). Callers also have to handle the failure mode
> whereby 'svnadmin' itself didn't exist (which goes back to your
> "failed
> exec reports 255" above).
>
Re: Using "svnadmin freeze"
Posted by Daniel Shahaf <da...@elego.de>.
Philip Martin wrote on Fri, May 31, 2013 at 14:23:35 +0100:
> Daniel Shahaf <da...@apache.org> writes:
>
> > On Fri, May 31, 2013 at 01:35:57PM +0100, Philip Martin wrote:
> >> I think something like that would work but I'm unsure whether we should
> >> provide it. I'm concerned that it would be making freeze special.
> >> Would we need to provide similar queries for upgrade, recover, pack,
> >> etc?
> >>
> >
> > For what it's worth:
> >
> > I wanted to add "Is a write-lock being held?" to 'svnadmin info'. That was
> > just on a hunch that it might be useful --- I didn't have a concrete use-case
> > (and that feature has not been implemented).
>
> I guess that would be implemented by a non-blocking attempt to get a
> lock. Occasionally it would see a commit holding a lock as well as the
> other longer running commands. I can't decide whether queries like
> that, or the freeze query, are useful.
>
> >> A timeout leads on to a question was about error handling. At present
> >> the return value of "svnadmin freeze repository program" is the return
> >> value of the external program provided freeze managed to run the
> >> program. If freeze failed to run the program for some reason then the
> >> return value is generated by svnadmin directly. There is no way to
> >> distinguish errors from 'program' from errors from 'svnadmin', they both
> >> return values in the range 0-255. Success, zero, is unambiguous but any
> >> error is difficult to interpret.
> >>
> >> I don't see any easy way round this. If we stop providing the 'program'
> >> error as the return value how else do we provide it?
> >
> > IIRC, some applications use the following strategy: "If execvp() failed,
> > exit 126; else, exit with the child's exit code (possibly zero)".
> >
> > Sorry, I don't remember which man page I saw that strategy in.
>
> At present a failed exec returns 255 (on my machine). The problem is
> that the external program can also return 255. If we document a value
> then callers know it is possible that exec failed but can't be sure.
>
Can't we just ask people who really care about all 8 bits of the child's
exit code to use the bindings?
> >> Invoke some post-freeze command and pass it as a parameter?
> >
> > I suppose the post-freeze command should be optional?
>
> I think so but I'm not sure how, or even if, it would work. Would we
> simply have the the same problem of how to return the post-freeze
> command status?
We'd have the failure mode that the freeze-hook failed to run (or ran
and exited non-zero). Callers also have to handle the failure mode
whereby 'svnadmin' itself didn't exist (which goes back to your "failed
exec reports 255" above).
Re: Using "svnadmin freeze"
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <da...@apache.org> writes:
> On Fri, May 31, 2013 at 01:35:57PM +0100, Philip Martin wrote:
>> I think something like that would work but I'm unsure whether we should
>> provide it. I'm concerned that it would be making freeze special.
>> Would we need to provide similar queries for upgrade, recover, pack,
>> etc?
>>
>
> For what it's worth:
>
> I wanted to add "Is a write-lock being held?" to 'svnadmin info'. That was
> just on a hunch that it might be useful --- I didn't have a concrete use-case
> (and that feature has not been implemented).
I guess that would be implemented by a non-blocking attempt to get a
lock. Occasionally it would see a commit holding a lock as well as the
other longer running commands. I can't decide whether queries like
that, or the freeze query, are useful.
>> A timeout leads on to a question was about error handling. At present
>> the return value of "svnadmin freeze repository program" is the return
>> value of the external program provided freeze managed to run the
>> program. If freeze failed to run the program for some reason then the
>> return value is generated by svnadmin directly. There is no way to
>> distinguish errors from 'program' from errors from 'svnadmin', they both
>> return values in the range 0-255. Success, zero, is unambiguous but any
>> error is difficult to interpret.
>>
>> I don't see any easy way round this. If we stop providing the 'program'
>> error as the return value how else do we provide it?
>
> IIRC, some applications use the following strategy: "If execvp() failed,
> exit 126; else, exit with the child's exit code (possibly zero)".
>
> Sorry, I don't remember which man page I saw that strategy in.
At present a failed exec returns 255 (on my machine). The problem is
that the external program can also return 255. If we document a value
then callers know it is possible that exec failed but can't be sure.
It doesn't just have to be exec that fails. The freeze could fail to
get a lock due to OS permissions or incorrect repository path. The
freeze could timeout if we add a timeout feature. We could document a
whole series of different errors but all are ambiguous when the program
errors are considered. The only thing the caller can rely on is
success/failure.
>> Write it to standard output in some known form?
>
> Couldn't the freeze command have printed arbitrary stuff to stdout and stderr?
That's why I think there is no easy solution.
>> Invoke some post-freeze command and pass it as a parameter?
>
> I suppose the post-freeze command should be optional?
I think so but I'm not sure how, or even if, it would work. Would we
simply have the the same problem of how to return the post-freeze
command status?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Using "svnadmin freeze"
Posted by Daniel Shahaf <da...@apache.org>.
On Fri, May 31, 2013 at 01:35:57PM +0100, Philip Martin wrote:
> I think something like that would work but I'm unsure whether we should
> provide it. I'm concerned that it would be making freeze special.
> Would we need to provide similar queries for upgrade, recover, pack,
> etc?
>
For what it's worth:
I wanted to add "Is a write-lock being held?" to 'svnadmin info'. That was
just on a hunch that it might be useful --- I didn't have a concrete use-case
(and that feature has not been implemented).
> A timeout leads on to a question was about error handling. At present
> the return value of "svnadmin freeze repository program" is the return
> value of the external program provided freeze managed to run the
> program. If freeze failed to run the program for some reason then the
> return value is generated by svnadmin directly. There is no way to
> distinguish errors from 'program' from errors from 'svnadmin', they both
> return values in the range 0-255. Success, zero, is unambiguous but any
> error is difficult to interpret.
>
> I don't see any easy way round this. If we stop providing the 'program'
> error as the return value how else do we provide it?
IIRC, some applications use the following strategy: "If execvp() failed,
exit 126; else, exit with the child's exit code (possibly zero)".
Sorry, I don't remember which man page I saw that strategy in.
> Write it to standard output in some known form?
Couldn't the freeze command have printed arbitrary stuff to stdout and stderr?
> Invoke some post-freeze command and pass it as a parameter?
I suppose the post-freeze command should be optional?
Re: Using "svnadmin freeze"
Posted by Julian Foad <ju...@btopenworld.com>.
Doug Robinson wrote:
> Philip:
>
> How do I subscribe to the dev list? Not sure I really have time for that... but perhaps.
I'm not Philip but I can tell you. Google("subversion dev mailing list subscribe")
-> <http://subversion.apache.org/mailing-lists.html>
-> email <de...@subversion.apache.org>
:-)
> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, [... blah blah ...]
Please ask Ian to disable the disclaimer for you, if you're going to post here from your WD email account, otherwise you'll annoy people and get flamed.
- Julian
Re: Using "svnadmin freeze"
Posted by Ben Reser <be...@reser.org>.
On Fri, May 31, 2013 at 7:34 AM, Doug Robinson
<do...@wandisco.com> wrote:
> How do I subscribe to the dev list? Not sure I really have time for that...
> but perhaps.
http://subversion.apache.org/mailing-lists.html
Re: Using "svnadmin freeze"
Posted by Doug Robinson <do...@wandisco.com>.
Philip:
How do I subscribe to the dev list? Not sure I really have time for
that... but perhaps.
Thank you.
Doug
On Fri, May 31, 2013 at 9:03 AM, Philip Martin
<ph...@wandisco.com>wrote:
> Doug,
>
> I started a thread on the dev list and meant to cc you but forgot.
> Don't feel any obligation to promote the ideas but do feel free to
> contibute if you want to.
>
> Philip Martin <ph...@codematters.co.uk> writes:
>
> > One of my colleagues at WANdisco asked some questions about using
> > freeze. The first thing he wanted to know is how to detect whether a
> > freeze is running. There are various approaches: look at running
> > processes, look at processes with the lock file open, implement some
> > external lock, etc. but none are reliable or portable. The only
> > reliable way to do it is for Subversion to provide some sort of
> > implementation.
> >
> > A freeze query might be implemented by having a separate freeze lock.
> > The freeze function itself would then take the freeze lock before taking
> > the write lock, and the freeze query would try a non-blocking lock of
> > the freeze lock. This would probably go into the repos layer to avoid
> > duplicate implementations.
> >
> > I think something like that would work but I'm unsure whether we should
> > provide it. I'm concerned that it would be making freeze special.
> > Would we need to provide similar queries for upgrade, recover, pack,
> > etc?
> >
> > A second point was about adding a timeout to freeze. At present freeze
> > blocks until it gets the write lock and will wait as long as it takes.
> > There is no timeout in APR's file locking API so to implement a timeout
> > we would need to either sit in a loop attempting non-blocking locks or
> > use SIGALARM to cause EINTR. I think that would work but again I'm
> > unsure how useful this feature would be.
> >
> > A timeout leads on to a question was about error handling. At present
> > the return value of "svnadmin freeze repository program" is the return
> > value of the external program provided freeze managed to run the
> > program. If freeze failed to run the program for some reason then the
> > return value is generated by svnadmin directly. There is no way to
> > distinguish errors from 'program' from errors from 'svnadmin', they both
> > return values in the range 0-255. Success, zero, is unambiguous but any
> > error is difficult to interpret.
> >
> > I don't see any easy way round this. If we stop providing the 'program'
> > error as the return value how else do we provide it? Write it to
> > standard output in some known form? Invoke some post-freeze command and
> > pass it as a parameter?
> >
> > --
> > Philip
> >
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
>
--
Douglas B. Robinson | *Senior Product Manager*
WANdisco // *Non-Stop Data*
t. 925-396-1125
e. doug.robinson@wandisco.com
--
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone. Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized. The views and
opinions expressed in this e-mail message are the author's own and may not
reflect the views and opinions of WANdisco, unless the author is authorized
by WANdisco to express such views or opinions on its behalf. All email
sent to or from this address is subject to electronic storage and review by
WANdisco. Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.