Re: svn freezing at checkout on FreeBSD

--0000000000005c91760648068734
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Den l=C3=B6r 10 jan. 2026 kl 11:38 skrev Michael Osipov <[email protected]=
g>:

> On 2025/12/21 20:14:38 Anton Shepelev wrote:
> > Hello, all.
> >
> > On FreeBSD 14.3, svn 1.14.2 freezes at the checkout operation of an
> > svn:// repository. The working-directory is created together with the
> > .svn subdirectory, but nothing else appears. If I kill the fronzen
> > svn process, and do `svn up', it says the working copy is already locke=
d.
> > If I do `svn cleanup', then `svn up' hangs forever as well.
> >
> > I have made sure that both /dev/random and /dev/urandom do not
> > block, by reading a single byte from them:
> >
> >   od -vAn -N2 -tu2 < /dev/random
> >   od -vAn -N2 -tu2 < /dev/urandom
> >
> > On FreeBSD, /dev/urandom is a symlink to /dev/random, but it
> > did not stop other and previous installation of FreeBSD.
> > Please, help me shoot this trouble, preferable in the head
> > rather than in the foot.
>
> I can confirm that on my end. I had those freezes in various Subversion
> versions and FreeBSD versions over the past could of years where the clie=
nt
> and the server are on the same machine accessed via HTTPS. I always assum=
ed
> that is was my setup and never analyzed it. It is hard to reproduce. Most
> of the time it has happended when:
> * Updated 100+ working copies at once in a loop
> * Performed "mvn release:prepare release:perform"
>
> I'd behappy to trace when this happens again, but need to know what
> exactly. truss? Wireshark?
>
> Michael
>

A Wireshark trace is always nice - then it might be possible to see who is
waiting for what. Of course, if it is hard to reproduce... To me it sounds
a lot like package loss (which should be handled on the TCP level or
suitably reported as a socket error).

Cheers,
 /Daniel

--0000000000005c91760648068734
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Den l=C3=B6r 10 jan. 2026 kl 11:38 skrev =
Michael Osipov &lt;<a href=3D"mailto:[email protected]">[email protected]=
rg</a>&gt;:</div><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">On 2025/12/21 20:14:38 Anton Shepe=
lev wrote:<br>
&gt; Hello, all.<br>
&gt; <br>
&gt; On FreeBSD 14.3, svn 1.14.2 freezes at the checkout operation of an<br=
>
&gt; svn:// repository. The working-directory is created together with the<=
br>
&gt; .svn subdirectory, but nothing else appears. If I kill the fronzen<br>
&gt; svn process, and do `svn up&#39;, it says the working copy is already =
locked.<br>
&gt; If I do `svn cleanup&#39;, then `svn up&#39; hangs forever as well.<br=
>
&gt; <br>
&gt; I have made sure that both /dev/random and /dev/urandom do not<br>
&gt; block, by reading a single byte from them:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0od -vAn -N2 -tu2 &lt; /dev/random<br>
&gt;=C2=A0 =C2=A0od -vAn -N2 -tu2 &lt; /dev/urandom<br>
&gt; <br>
&gt; On FreeBSD, /dev/urandom is a symlink to /dev/random, but it<br>
&gt; did not stop other and previous installation of FreeBSD.<br>
&gt; Please, help me shoot this trouble, preferable in the head<br>
&gt; rather than in the foot.<br>
<br>
I can confirm that on my end. I had those freezes in various Subversion ver=
sions and FreeBSD versions over the past could of years where the client an=
d the server are on the same machine accessed via HTTPS. I always assumed t=
hat is was my setup and never analyzed it. It is hard to reproduce. Most of=
 the time it has happended when:<br>
* Updated 100+ working copies at once in a loop<br>
* Performed &quot;mvn release:prepare release:perform&quot;<br>
<br>
I&#39;d behappy to trace when this happens again, but need to know what exa=
ctly. truss? Wireshark?<br>
<br>
Michael<br></blockquote><div><br></div><div>A Wireshark trace is always nic=
e - then it might be possible to see who is waiting for what. Of course, if=
 it is hard to reproduce... To me it sounds a lot like package loss (which =
should be handled on the TCP level or suitably reported as a socket error).=
</div><div><br></div><div>Cheers,</div><div>=C2=A0/Daniel</div></div></div>

--0000000000005c91760648068734--