Re: svn freezing at checkout on FreeBSD
Branko Čibej <[email protected]> Tue, 23 Dec 2025 02:47:29 +0100
| Newsgroups | gmane.comp.version-control.subversion.user |
|---|---|
| Organization | The Apache Software Foundation |
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------NUXQFrpH2gpBIHNSpBETdZ3m
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 22. 12. 25 22:54, Anton Shepelev wrote:
> Branko Cibej to Anton Shepelev:
>
>>> On FreeBSD 14.3, svn 1.14.2
>> Out of interest, where did you get this version? I have a VM
>> with FreeBSD 14.2 and the Subversion in ports is version
>> 1.14.5.
> Probably an unfinished upgrade from 14.1. After `pkg upgrade
> -f' (which fixed some other errors), my Subversion is 1.14.5
> (r1922182). The issue persists.
>
>>> 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
>>>
>> Reading one byte won't tell you much. You just tested that the
>> entropy pool isn't empty. Try reading 100 or 1000 bytes,
>> that's a more realistic test.
> It works, too.
>
>> Subversion itself uses randomness -- via APR's
>> apr_generate_random_bytes(), which uses /dev/urandom on
>> FreeBSD -- to encrypt passwords on disk. This is an optional
>> feature and doesn't seem to be enabled in the port. And
>> anyway, /dev/urandom is guaranteed not to block, see
>> https://s.apache.org/7v30k .
> I thought urandom was symlinked from random, but checking currnt
> FreeBSD docs shows it is not (or no longer) so. OK.
Even if they are, the expected behaviour is that /dev/random may block
but /dev/urandom won't. That's the whole reason why /dev/urandom was
introduced.
>> Given all of the above, what evidence do you have that your
>> checkout is blocking on /dev/[u]random ->
> It is the only reason I have seen mentioned in connexion with an
> infinte blocking of svn.
>
>> -> and not, for example, on DNS resolution?
> In case specifically of DNS resolution, svn does not hang
> forever. Futhermore, `svn up' and `svn ls' do not freeze on the
> affected system, from working directories connected to the same
> repo which it hangs with during co. My latest test shows that
> `svn co' get all the files excep the last one (alphabetically).
> and only then hangs:
>
> <https://paste.c-net.org/RadioBanging>
Now that's ... "interesting". Previously you wrote,
> On 21. 12. 25 21:14, Anton Shepelev wrote:
>
>> If I do `svn cleanup', then `svn up' hangs forever as well.
>
So this seems not to be the case. Can you try something like this:
ac8 ant> svn cosvn://<hidden> &
and then, while the svn job is blocked in the background:
ac8 ant> lsof | grep '/dev/u*random'
That will show if the Subversion process has one of the random devices
open. You can also try 'lsof | grep svn'.
-- Brane
--------------NUXQFrpH2gpBIHNSpBETdZ3m
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 22. 12. 25 22:54, Anton Shepelev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">Branko Cibej to Anton Shepelev:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">On FreeBSD 14.3, svn 1.14.2
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Out of interest, where did you get this version? I have a VM
with FreeBSD 14.2 and the Subversion in ports is version
1.14.5.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Probably an unfinished upgrade from 14.1. After `pkg upgrade
-f' (which fixed some other errors), my Subversion is 1.14.5
(r1922182). The issue persists.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">Reading one byte won't tell you much. You just tested that the
entropy pool isn't empty. Try reading 100 or 1000 bytes,
that's a more realistic test.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
It works, too.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Subversion itself uses randomness -- via APR's
apr_generate_random_bytes(), which uses /dev/urandom on
FreeBSD -- to encrypt passwords on disk. This is an optional
feature and doesn't seem to be enabled in the port. And
anyway, /dev/urandom is guaranteed not to block, see
<a class="moz-txt-link-freetext" href="https://s.apache.org/7v30k">https://s.apache.org/7v30k</a> .
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
I thought urandom was symlinked from random, but checking currnt
FreeBSD docs shows it is not (or no longer) so. OK.</pre>
</blockquote>
<br>
<br>
Even if they are, the expected behaviour is that <font
face="monospace">/dev/random</font> may block but <font
face="monospace">/dev/urandom</font> won't. That's the whole
reason why <font face="monospace">/dev/urandom</font> was
introduced.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:[email protected]">
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Given all of the above, what evidence do you have that your
checkout is blocking on /dev/[u]random ->
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
It is the only reason I have seen mentioned in connexion with an
infinte blocking of svn.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">-> and not, for example, on DNS resolution?
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
In case specifically of DNS resolution, svn does not hang
forever. Futhermore, `svn up' and `svn ls' do not freeze on the
affected system, from working directories connected to the same
repo which it hangs with during co. My latest test shows that
`svn co' get all the files excep the last one (alphabetically).
and only then hangs:
<a class="moz-txt-link-rfc2396E" href="https://paste.c-net.org/RadioBanging"><https://paste.c-net.org/RadioBanging></a></pre>
</blockquote>
<br>
Now that's ... "interesting". Previously you wrote,<br>
<br>
<blockquote type="cite">On 21. 12. 25 21:14, Anton Shepelev wrote:<br>
<br>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">If I do `svn cleanup', then `svn up' hangs forever as well.</pre>
</blockquote>
<br>
</blockquote>
<br>
So this seems not to be the case. Can you try something like this:<br>
<br>
<blockquote>
<pre>ac8 ant> svn co <a class="moz-txt-link-freetext" href="svn://">svn://</a><hidden> &</pre>
</blockquote>
<br>
and then, while the svn job is blocked in the background:<br>
<br>
<blockquote>
<pre>ac8 ant> lsof | grep '/dev/u*random'</pre>
</blockquote>
<br>
That will show if the Subversion process has one of the random
devices open. You can also try '<font face="monospace">lsof | grep
svn</font>'.<br>
<br>
<br>
-- Brane
</body>
</html>
--------------NUXQFrpH2gpBIHNSpBETdZ3m--