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
