You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David James <ja...@gmail.com> on 2005/06/22 02:07:36 UTC
Client hangs when svnserve does not respond
Here's a simple way to hang your Subversion client.
$ svnserve -d
$ killall -STOP svnserve
$ svn cat svn://localhost/
It appears to me that 'svn cat' never times out if we have a svnserve
process that is not responding. Is this behaviour intended?
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by Christopher Ness <ch...@nesser.org>.
On Wed, 2005-08-03 at 00:51 +0100, Julian Foad wrote:
> David James wrote:
> > On 8/2/05, Julian Foad <ju...@btopenworld.com> wrote:
> >
> >>The problem, as I understand it, is that in several different cases the user
> >>can't interrupt Subversion during a system call that is taking too long. This
> >>is because our SIGINT handler just sets a flag when they press Ctrl-C and
> >>doesn't do anything else. We should be able to modify our SIGINT handler to
> >>avoid that problem. It should set the flag, and then arrange that if a second
> >>SIGINT should be received, it will unconditionally terminate the application.
> >>It can probably do so by uninstalling itself, so that any future SIGINT has the
> >>default handling. [*]
Posting without the fear of being laughed at.
Could the signal sent be handled by forking a new process (or thread) to
clean up anything that needs cleaning in the background.
Then uninstall the handler and send another SIGINT to the process to
terminate it while the new back grounded process cleans up with WC.
This would appear to return the user to a prompt right away after
pressing C-c -- I think.
This way there would be fast exits w.r.t the user and clean ones w.r.t
the working copy (is it the WC that needs cleaning? it must be...).
If the cleanup process ever hung it would be problematic, but not the
end of the world.
Other than the obvious complications this would bring about by forking a
new process to clean up what do people think? Could it be done?
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
22:11:18 up 3:53, 2 users, load average: 0.27, 0.61, 0.33
Re: Client hangs when svnserve does not respond
Posted by Julian Foad <ju...@btopenworld.com>.
David James wrote:
> On 8/2/05, Julian Foad <ju...@btopenworld.com> wrote:
>
>>The problem, as I understand it, is that in several different cases the user
>>can't interrupt Subversion during a system call that is taking too long. This
>>is because our SIGINT handler just sets a flag when they press Ctrl-C and
>>doesn't do anything else. We should be able to modify our SIGINT handler to
>>avoid that problem. It should set the flag, and then arrange that if a second
>>SIGINT should be received, it will unconditionally terminate the application.
>>It can probably do so by uninstalling itself, so that any future SIGINT has the
>>default handling. [*]
>
> This sounds like a good solution.
Thanks. Sadly I'm in no position to write the patch.
> How do you suggest we deal with
> other signals, such as SIGTERM and SIGHUP?
I have never thought about them. I suppose what you are thinking is that they
also ought to give Subversion a chance to clean up rather than just abort
uncleanly. The only thing I can think of, off the top of my head, is to
install handlers for them that set the "interrupted" flag and then start an
operating-sytem-provided timer that will send some untrapped signal after one
second (or ten or whatever) to kill the application. If the application
reaches its normal exit before that, it will deactivate the timer. The
feasibility of this approach depends on whether suitable facilities are
provided by the operating system. I've no idea whether they are.
However, we should not let the thought of improving our response to those other
signals distract us from handling SIGINT (Ctrl-C) as best we can.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by David James <ja...@gmail.com>.
On 6/23/05, Greg Hudson <gh...@mit.edu> wrote:
> Yeah, we could set a timeout on the socket and call the cancellation
> function between repeated read calls, assuming the cancellation function
> is available to the RA layer.
I'd love to see this implemented. It's much better to avoid unclean
exits, if we can, because we won't need to run "svn cleanup". By
building timeouts into the system, we'll have a more robust protocol.
David James wrote:
> I like Julian's idea because it's simple [...]
Oops. :) Greg's idea is also simple, and it solves the problem entirely!
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by David James <ja...@gmail.com>.
On 8/2/05, Greg Hudson <gh...@mit.edu> wrote:
> On Tue, 2005-08-02 at 18:41 -0400, David James wrote:
> > On 8/2/05, Julian Foad <ju...@btopenworld.com> wrote:
> > > The problem, as I understand it, is that in several different cases the user
> > > can't interrupt Subversion during a system call that is taking too long. This
> > > is because our SIGINT handler just sets a flag when they press Ctrl-C and
> > > doesn't do anything else. We should be able to modify our SIGINT handler to
> > > avoid that problem. It should set the flag, and then arrange that if a second
> > > SIGINT should be received, it will unconditionally terminate the application.
> > > It can probably do so by uninstalling itself, so that any future SIGINT has the
> > > default handling. [*]
> > This sounds like a good solution. How do you suggest we deal with
> > other signals, such as SIGTERM and SIGHUP?
>
> Why does it sound like a good solution? It's the easy way out; we'll be
> creating a bunch of unclean exit situations because we're too lazy to
> engineer a proper solution.
I like Julian's idea because it's simple -- he's not overengineering.
His solution sounds like it will be simple and very portable.
In the case of the SIGINT handler, I'm not that worried about unclean
exit situations -- it's common and expected for programs to exit
uncleanly if you tap CTRL-C multiple times. That's why the operating
system aborts the program by default if you tap CTRL-C. (The SIGHUP
and SIGTERM signals may need to be handled more carefully.)
Other ideas?
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-08-02 at 18:41 -0400, David James wrote:
> On 8/2/05, Julian Foad <ju...@btopenworld.com> wrote:
> > The problem, as I understand it, is that in several different cases the user
> > can't interrupt Subversion during a system call that is taking too long. This
> > is because our SIGINT handler just sets a flag when they press Ctrl-C and
> > doesn't do anything else. We should be able to modify our SIGINT handler to
> > avoid that problem. It should set the flag, and then arrange that if a second
> > SIGINT should be received, it will unconditionally terminate the application.
> > It can probably do so by uninstalling itself, so that any future SIGINT has the
> > default handling. [*]
> This sounds like a good solution. How do you suggest we deal with
> other signals, such as SIGTERM and SIGHUP?
Why does it sound like a good solution? It's the easy way out; we'll be
creating a bunch of unclean exit situations because we're too lazy to
engineer a proper solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by David James <ja...@gmail.com>.
On 8/2/05, Julian Foad <ju...@btopenworld.com> wrote:
> The problem, as I understand it, is that in several different cases the user
> can't interrupt Subversion during a system call that is taking too long. This
> is because our SIGINT handler just sets a flag when they press Ctrl-C and
> doesn't do anything else. We should be able to modify our SIGINT handler to
> avoid that problem. It should set the flag, and then arrange that if a second
> SIGINT should be received, it will unconditionally terminate the application.
> It can probably do so by uninstalling itself, so that any future SIGINT has the
> default handling. [*]
This sounds like a good solution. How do you suggest we deal with
other signals, such as SIGTERM and SIGHUP?
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> On Thu, 2005-06-23 at 09:47 -0500, kfogel@collab.net wrote:
>
>>If that's the issue, we could either:
>>
>> a) Untrap the interrupt handler during that wait.
>> b) Wait for the server in a non-blocking or semi-blocking way.
>>
>>I'm hand-waving a bit, but are there any solutions along these lines?
>
> Yeah, we could set a timeout on the socket and call the cancellation
> function between repeated read calls, assuming the cancellation function
> is available to the RA layer.
>
> That's not really the ideal solution; from the perspective of what
> system calls we generate, it would be better to make sure that the
> read() isn't set to be restartable and call the cancellation function
> when we get the EINTR. But I'm not sure if APR makes that feasible. I
> think it blithely restarts system calls under the covers without
> considering this issue.
Let the behaviour be: Ctrl-C requests an abort; a second Ctrl-C forces an abort.
The problem, as I understand it, is that in several different cases the user
can't interrupt Subversion during a system call that is taking too long. This
is because our SIGINT handler just sets a flag when they press Ctrl-C and
doesn't do anything else. We should be able to modify our SIGINT handler to
avoid that problem. It should set the flag, and then arrange that if a second
SIGINT should be received, it will unconditionally terminate the application.
It can probably do so by uninstalling itself, so that any future SIGINT has the
default handling. [*]
Please don't argue that "The user might press Ctrl-C twice in quick succession
and thereby cause an unclean abort in cases when he would have got a clean
abort if he had waited a second or three. Therefore we shouldn't do this
because that would inconvenience such users." If such considerations are
really a serious concern then there are ways to address them such as time delays.
- Julian
[*] A possible but unlikely alternative: The handler could say, "if (flag is
already set) then { abort() }". But I don't know if an interrupt handler can
abort the application; probably not, or it may depend on whether the C library
implementors consciously arranged for the "abort()" call to handle that special
case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-06-23 at 09:47 -0500, kfogel@collab.net wrote:
> If that's the issue, we could either:
>
> a) Untrap the interrupt handler during that wait.
> b) Wait for the server in a non-blocking or semi-blocking way.
>
> I'm hand-waving a bit, but are there any solutions along these lines?
Yeah, we could set a timeout on the socket and call the cancellation
function between repeated read calls, assuming the cancellation function
is available to the RA layer.
That's not really the ideal solution; from the perspective of what
system calls we generate, it would be better to make sure that the
read() isn't set to be restartable and call the cancellation function
when we get the EINTR. But I'm not sure if APR makes that feasible. I
think it blithely restarts system calls under the covers without
considering this issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by kf...@collab.net.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > Not intended, but also not completely unreasonable. Should it ever
> > time out? Someone can interrupt if they're upset, but maybe it's just
> > a really, really slow link...
> >
> Ha, they'll be even more upset when they discover that they can't (easily)
> interrupt;). Suspending, then kill -9 on Unix is the only way I succeeded.
>
> This is a boring problem. If the server stops responding at all, we just
> set a flag and never reach a cancelation check. I don't know how to fix
> this. We want to run cleanup, but we don't want interrupted system calls
> to be restarted.
Why exactly can't they interrput? Because we're trapping the
interrupt signal to handle by polling periodically, and we don't have
any poll calls going on while we wait for the server's response?
If that's the issue, we could either:
a) Untrap the interrupt handler during that wait.
b) Wait for the server in a non-blocking or semi-blocking way.
I'm hand-waving a bit, but are there any solutions along these lines?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 22 Jun 2005 kfogel@collab.net wrote:
> David James <ja...@gmail.com> writes:
> > Here's a simple way to hang your Subversion client.
> >
> > $ svnserve -d
> > $ killall -STOP svnserve
> > $ svn cat svn://localhost/
> >
> > It appears to me that 'svn cat' never times out if we have a svnserve
> > process that is not responding. Is this behaviour intended?
>
> Not intended, but also not completely unreasonable. Should it ever
> time out? Someone can interrupt if they're upset, but maybe it's just
> a really, really slow link...
>
Ha, they'll be even more upset when they discover that they can't (easily)
interrupt;). Suspending, then kill -9 on Unix is the only way I succeeded.
This is a boring problem. If the server stops responding at all, we just
set a flag and never reach a cancelation check. I don't know how to fix
this. We want to run cleanup, but we don't want interrupted system calls
to be restarted.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Client hangs when svnserve does not respond
Posted by kf...@collab.net.
David James <ja...@gmail.com> writes:
> Here's a simple way to hang your Subversion client.
>
> $ svnserve -d
> $ killall -STOP svnserve
> $ svn cat svn://localhost/
>
> It appears to me that 'svn cat' never times out if we have a svnserve
> process that is not responding. Is this behaviour intended?
Not intended, but also not completely unreasonable. Should it ever
time out? Someone can interrupt if they're upset, but maybe it's just
a really, really slow link...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org