On 26. 12. 25 12:34, Anton Shepelev wrote:
Branko Cibej to Anton Shepelev:
IMHO, it would be more polite of svn to fail and
explain which operation timed out.
Clearly nothing has timed out, that's why the process
is blocked.
Yes, and my point is that a tool should ensure that all
potentially blocking operations time out after a finite
length of time, whenever possible.
Subversion does use timeouts, if not explicitly, then system-defined ones.
I think dtrace/strace would be the next thing to try
yes.
Unavailable on FreeBSD, but I have tried ktrace[1] and
truss[2], but in vain -- they did not indicate a
blocking call. I called ktrace only with the default
parameters, and have yet to try the most detailed and
extensive logging it is capable of.
By sheer experment, however, I seem to have determined
the culprit -- the mobile internet, used by the affected
machine via a Wi-Fi hot-spot on a smartphone: Checking
out the same repository via an SSH tunnel stably
succeeds. I don't know whether it is because of some
additional reliability of SSH, or its encryption,
prevening the mobile provider from analysing the traffic
and concluding it suspicious.
I've seen "smart" firewalls with deep packet inspection drop TCP packets
randomly, in one case (I'm looking at you, Cisco }:( ) because of buffer
overruns on the firewall box. This will cause endless packet retransmits
but won't actually block all throughput. Who knows what the system's TCP
stack is doing, and how long, if at all, it's prepared to grind on
before it gives up.
In spite of the workaround, I still should like to
understand why `svn co' blocks forever on mobile
internet. This is not right.
There's really nothing much Subversion can do about this. If the OS
doesn't report an error on the socket, we'll just keep polling it.
Transmit timeouts on sockets are usually quite long by default, and if
something actually is happening, the OS may not decide there's something
wrong.
Yes, Subversion, and specifically the svn:// protocol, was not designed
to be resilient on a flaky network. That's the network stack's job. I'll
admit it's not military-grade EMP-resistant.
Beg pardon for delayed replies. I access the
affected system remotely, via a reverse SSH tunnel
established by autossh, at the relatively rare times
the machine is online.
That's really not a problem. We all accept that e-mail
is asynchronous.
Indeed,<https://justuseemail.com/> .
Nay, we revel in it! :D
A reader of Victorian literature detected.
Elisabethan. "Our revels now are ended," &c. &c. But not recently.
-- Brane
