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. > 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. In spite of the workaround, I still should like to understand why `svn co' blocks forever on mobile internet. This is not right. > > 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. ____________________ 1. <https://man.freebsd.org/cgi/man.cgi?ktrace> 2. <https://man.freebsd.org/cgi/man.cgi?query=truss>
